What the SoA really is
Ce qu'est réellement la SoA
The SoA is the organization's control position. It records which Annex A controls apply, why they apply or do not apply, and what implementation status the organization can stand behind.
Build a realistic SoA with traceable applicability, implementation rationale, and evidence expectations
This builder now teaches what the SoA is, why auditors care, how applicability links to treatment decisions, what weak rationale looks like, and what evidence a stronger SoA position should point to.
Why auditors care
Pourquoi les auditeurs y tiennent
Auditors use the SoA to test traceability. If applicability and implementation cannot be linked to risks, obligations, or context, confidence in the ISMS drops quickly.
What weak SoA practice looks like
À quoi ressemble une pratique SoA faible
Weak SoA practice uses blanket statements, generic 'best practice' logic, no risk linkage, and no evidence expectation for implemented controls.
What good SoA practice looks like
À quoi ressemble une bonne pratique SoA
Good SoA practice explains the reason for applicability, names the business context or risk, shows implementation status honestly, and points to evidence an auditor can sample.
5.1OrganizationalDirective
Policies for information security
Politiques de sécurité de l'information
Set the direction and rules for information security.
Applicability
Implementation status
Link to treatment logic
Business meaning
Policies for information security matters in business terms because it makes governance and compliance decisions repeatable, reviewable, and easier to defend with evidence.
Example implementation
For policies for information security, a typical implementation combines a documented rule, an operational owner, and recurring evidence that the rule is actually followed.
Good rationale
Policies for information security matters in business terms because it makes governance and compliance decisions repeatable, reviewable, and easier to defend with evidence.
Weak rationale
This control is applicable because it is generally useful.
Expected evidence
- Typical evidence: policy versions, approved procedures, governance minutes, supplier clauses, or exception records. / Preuves typiques : versions de politiques, procédures approuvées, comptes rendus de gouvernance, clauses fournisseurs ou registres d'exception.
- Evidence should show who owns control 5.1, how it is performed, and how exceptions are tracked. / La preuve doit montrer qui porte la mesure 5.1, comment elle est exécutée et comment les exceptions sont suivies.
Auditor challenge
Show how this control position is reflected in sampled evidence, not only in design documents.
Common SoA mistakes
Learner-friendly SoA summary
0 controls with explicit decisions
Applicable controls
0
Weak rationales
0
Missing risk links
0
Missing evidence notes
0
Start marking controls as applicable or not applicable to generate the SoA summary.
Bilingual SoA language
Useful phrasing for explaining applicability, traceability, and evidence quality during workshops or audits.
Describing control maturity
implementationEnglish
The control is partially implemented.
Français
La mesure est partiellement mise en oeuvre.
Useful when the design exists but execution or evidence is still incomplete.
Explaining poor traceability
riskEnglish
The risk treatment decision is not traceable.
Français
La décision de traitement du risque n'est pas traçable.
Useful when a register exists but treatment logic cannot be linked to owners, dates, or controls.
Commenting on SoA quality
soaEnglish
The SoA rationale is too generic for audit reliance.
Français
La justification de la SoA est trop générique pour être fiable en audit.
Useful when applicability statements are broad, unsupported, or disconnected from risk treatment.
Organizational
37
Policies, governance, supplier oversight, incident management, continuity, and compliance.
People
8
Awareness, hiring, offboarding, remote work, and human behavior.
Physical
14
Premises, visitors, equipment, disposal, and environmental protection.
Technological
34
Identity, logging, vulnerabilities, backups, networks, and secure development.