Compliance, SoA and controls #

Purpose and tabs #

Compliance brings together Assessments, Repositories and SoA & controls. Administrators manage standards/requirements; the evaluators provide the authorized results.

References and evaluations #

A repository contains active requirements. Create an assessment with baseline, scope, evaluator and date: RiskPilot generates one result per requirement. Enter maturity 0–5, status compliant/partial/non-compliant/not applicable/not assessed, proof and corrective action.

SoA and testing #

The applicability statement links requirements, controls, risks, actions and evidence. The admin approver is different from the manager. An approved version is immutable; Review creates the next one. Tests describe design or effectiveness, procedure, frequency, tester, sample, result, evidence and next review.

Correspondence and exports #

Mappings between requirements reuse a proof with provenance and coverage. Assessments and SoA are exported in CSV UTF-8. The overall score excludes not applicable and not assessed.

Errors and practices #

Do not use “not applicable” to hide a gap. Maintain justification, separate responsible and approver, and plan for testing.

Roles and prerequisites #

An administrator creates the repository and its requirements. Before an assessment, create the scope and designate an active assessor. The associated evidence, controls, risks and actions must belong to the same tenant.

Repositories tab #

A repository has a name, version, and active requirements. Use a stable identifier per requirement and verifiable text. A version change must be governed: do not silently change the meaning of an already evaluated requirement.

Create an assessment #

1. Select Assessments then create.
2. Choose baseline, scope, evaluator and date.
3. Save to generate one result per active requirement.
4. For each outcome, assign maturity 0–5 and status.
5. Add justification, evidence and corrective action if necessary.
6. Review unevaluated results before synthesis.

Status and maturity #

Maturity measures mastery of the system and should not be automatically deduced from status. The overall score excludes Not Applicable and Not Evaluated.

Applicability statement #

Create the SoA for a baseline and scope, then document applicability, justification, control, risk, action, and evidence for each line. The manager prepares; a separate administrator approves. After approval, the version is frozen. Revise duplicates the lines in a new version.

Control testing #

Choose design or operational efficiency. Document procedure, frequency, tester, population/sample, result, evidence and next review. Failure should lead to analysis and, if necessary, corrective action.

Multi-standard correspondences #

A match connects two requirements and specifies coverage. A legacy proof retains its provenance: verify that it actually meets the target text before reusing it.

Exports and controlsCSV exports of assessments and SoA remain tenant-scoped. Before distribution, check version, scope, date, unassessed elements, N/A justifications, separate approver and proof links still accessible. #

Common errors #

A missing requirement may be inactive. An approved SoA is intentionally non-modifiable. Visible proof in another result is not automatically sufficient: the coverage of the mapping must be explained.

Results and action plans #

Compliance results can link directly to action plans. Use the relationship to track owner, due date, progress and evidence without duplicating the non-conformity. Cross-organization relationships are rejected.

Governed starter packs #

The Linux/Docker command php bin/console app:compliance:install-starter-packs installs four idempotent name/version baselines: RGPD 2016/679 (11 requirements), NIS2 2022/2555 (10), ISO/IEC 27001:2022 (8 metadata entries) and EBIOS Risk Manager 2018 (5 workshops). A second run skips existing packs.

RGPD and NIS2 use public European texts, while EBIOS follows the five public workshops. The ISO pack reproduces no protected standard text: a licensed copy remains mandatory. These packs start governance; they are not legal advice, a declaration of conformity or certification. Adapt requirements, evidence, owners and scopes before assessment.

Assessment maturity radar #

After selecting an assessment, the radar displays only requirements actually assessed from 0 to 5. NOT_ASSESSED and NOT_APPLICABLE requirements are excluded from both radar and average. Levels 0–2 are weaknesses, 4–5 strengths, unassessed requirements remain to complete, and not-applicable items are counted separately. The radar appears once at least three requirements are assessed. Optimistic UI updates roll back when the API rejects them.

Status accepts COMPLIANT, PARTIAL, NON_COMPLIANT, NOT_APPLICABLE or NOT_ASSESSED. Linked actions, evidence and resources must belong to the same organization. Updating one field must preserve unchanged relationships.

Assessment creation and lifecycle #

On creation, RiskPilot displays the framework's active-point count and automatically creates one NOT_ASSESSED result for each. The framework becomes immutable after launch; scope, assessor, date and status remain editable by an administrator, Risk manager, auditor or the assigned assessor.

The displayed lifecycle is DRAFT → IN_PROGRESS → COMPLETED, then ARCHIVED when needed. Moving to COMPLETED notifies the assessor and locks result entry in the interface. A completed or archived assessment must return to IN_PROGRESS before correction. The compliance dashboard consolidates COMPLETED assessments only.

The status selector calls PUT /api/compliance-assessments/{id} with framework, scope, assessor, date and new status. The framework cannot be replaced (FRAMEWORK_IMMUTABLE). Results remain editable only by authorized roles or the assessor, and failed updates immediately restore the previous screen value.

AI assistance for a requirement #

The AI copilot button on a result first calls GET /api/compliance-results/{id}/copilot/context. The user reviews MINIMAL or CONTEXTUAL data, then explicitly consents to every POST. Conversation history contains at most eight messages; the answer cites the requirement, changes no field and audits only technical metadata and the question hash. Stable errors and a JSON example are documented under AI copilot.