-
Notifications
You must be signed in to change notification settings - Fork 2
Specs M2 Assets Supplier Requirement
assets.models.supplier.SupplierRequirement
Requirement imposed on a supplier (for example "Valid ISO 27001 certification", "Recovery plan tested annually", "Incident notification within 24 h"). Can be created manually, derived from a SupplierTypeRequirement (template attached to the type) or linked to a compliance.Requirement of the ISMS. Its compliance is assessed and reviewed periodically via SupplierRequirementReview records.
| Field | Type | Constraints | Description |
|---|---|---|---|
id |
int | PK auto-incremented | Numeric identifier |
supplier |
FK -> Supplier | required, cascade | Supplier concerned |
source_type_requirement |
FK -> SupplierTypeRequirement | optional | Origin if the requirement derives from a type template |
requirement |
FK -> compliance.Requirement | optional | Link to the ISMS requirement it relates to (the same ISO control can be imposed on several suppliers) |
title |
string | required, max 500 | Custom title, especially useful when requirement is not set |
description |
text | optional | |
compliance_status |
enum | required, default not_assessed
|
not_assessed, compliant, partially_compliant, non_compliant
|
evidence |
text | optional | Description of the evidence (document references, screenshots, etc.) |
due_date |
date | optional | Contractual deadline |
verified_at |
datetime | optional | Date of the last verification, updated on each SupplierRequirementReview
|
verified_by |
FK -> User | optional | Author of the last verification |
created_at / updated_at
|
datetime | auto |
assets.models.supplier.SupplierRequirementReview
Review / justification record associated with a SupplierRequirement. Several reviews per requirement make it possible to reconstruct the compliance history and to attach dated evidence (audit, up-to-date certificate, incident report).
| Field | Type | Constraints | Description |
|---|---|---|---|
id |
int | PK auto-incremented | |
supplier_requirement |
FK -> SupplierRequirement | required, cascade | |
review_date |
date | required | Date of the review |
reviewer |
FK -> User | optional | |
result |
enum | required, default not_assessed
|
Same enumeration as compliance_status above |
comment |
text | optional | Written justification |
evidence_file |
text | optional | Uploaded data-URI document |
evidence_filename |
string | optional, max 255 | Original file name |
created_at / updated_at
|
datetime | auto |
When a review with a final result is saved, the parent requirement updates its compliance_status, verified_at and verified_by from the most recent review.
-
not_assessed: requirement created but never assessed. No alert. -
compliant: compliant. Next review date computed from thedue_dateor the frequency defined at the type level. -
partially_compliant: requirement partially satisfied (some parts yes, others no). Mild alert. -
non_compliant: non-compliant. Critical alert, contributes to the dashboard counter.
| ID | Rule |
|---|---|
| RG-SREQ-01 | A SupplierRequirement must have a non-empty title even if requirement is linked: the title serves the quick listing without loading the ISMS requirement. |
| RG-SREQ-02 |
source_type_requirement is immutable once set. To replace the source, duplicate the requirement. |
| RG-SREQ-03 | When a SupplierRequirementReview is saved, its result propagates to the compliance_status of the parent requirement, and verified_at / verified_by reflect the review. |
| RG-SREQ-04 | A SupplierRequirement with a non_compliant status or with a past due_date and no review appears in the supplier's alert queue and counts in Supplier.requirement_compliance_summary. |
GET /api/v1/assets/supplier-requirements/POST /api/v1/assets/supplier-requirements/GET /api/v1/assets/supplier-requirements/<id>/PUT/PATCH /api/v1/assets/supplier-requirements/<id>/DELETE /api/v1/assets/supplier-requirements/<id>/-
GET /api/v1/assets/supplier-requirement-reviews/(full CRUD)
-
list_supplier_requirements/get_supplier_requirement/create_supplier_requirement/update_supplier_requirement/delete_supplier_requirement/batch_create_supplier_requirements -
list_supplier_requirement_reviews/create_supplier_requirement_review/delete_supplier_requirement_review
Supplier requirements and their reviews use the assets.supplier.* permission prefix (inherited from the parent Supplier entity).
- Supplier: parent entity
- Requirement: repository of linkable ISMS requirements
Built from docs/ at v0.36.0. Edits made here are overwritten by the next release : open a pull request against the source instead.
- Administration
- Ask Cairn
- Assets and suppliers
- Compliance
- The dashboard
- Finding your way
- Getting started
- Incidents
- How records move
- Organisational context
- Reports and management review
- Risks
- Trust Center
- Architecture
- Configuration
- Contributing
- The documentation system
- Installation
- Internationalisation
- Operations
- Release process
- Security
- Testing
- Adding an assistant provider
- Adding a dashboard widget
- Adding a domain entity
- Declaring a lifecycle
- Adding an MCP tool
- Adding a REST endpoint
- Adding a report
- Interface conventions
- Dashboard widgets
- Lifecycles
- MCP tools
- MCP tool parameters : Assets
- MCP tool parameters : Compliance
- MCP tool parameters : Governance and context
- MCP tool parameters : General
- MCP tool parameters : Incidents
- MCP tool parameters : Reports and management review
- MCP tool parameters : Risks
- MCP tool parameters : System and administration
- MCP tool parameters : Trust Center
- Management commands
- Models
- Permissions
- REST endpoints
- Environment variables
- MCP server
- REST API
- Assistant module (Ask Cairn)
- Module 0: User Management and Access Control
- Module 1: Context and Organization
- Module 2: Asset Management
- Module 3: Compliance
- Module 4: Risk Management
- Module 4 bis - EBIOS Risk Manager
- Module 5 : Trust Center
- Module 6 : Security Incident Management
- Management review : ISO 27001:2022 compliance (clause 9.3)