Documenting SoA

The Statement of Applicability (SoA) is a foundational document in ISO 27001 ISMS implementation, detailing which controls from the standard are applicable to an organization’s risk profile. It serves as a documentation tool that outlines control decisions and their rationale, ensuring alignment with legal, regulatory, and business requirements. Documenting the SoA requires a structured approach, ongoing maintenance, and integration with broader compliance processes.

Structure of the Statement of Applicability¶

The SoA should be organized to clearly communicate control decisions and their rationale. A standardized format ensures clarity and audit readiness. Key sections include:

1. Control ID and Title¶

Reference the ISO 27001 Annex A control ID (e.g., A.8.1.1) and full title.
Example:
| Control ID | Control Title |
|----------------|-------------------|
| A.8.1.1 | Information Security Policy |

2. Applicability Decision¶

Clearly state whether the control is applied, not applied, or modified.
Example:
| Applicability | Rationale |
|-------------------|---------------|
| Applied | Regulatory requirement for data protection under GDPR. |

3. Rationale and Justification¶

Document the reasoning for each decision, including risk assessments, legal obligations, or operational constraints.

Example:

**Rationale**:  
- GDPR Article 30 mandates record-keeping of processing activities.  
- The organization’s data handling processes align with this requirement.

4. References¶

Link to supporting documents (e.g., risk assessments, legal contracts, or internal policies).

Example Table:

| Control ID | Control Title               | Applicability | Rationale | References          |
|------------|-----------------------------|---------------|-----------|---------------------|
| A.8.1.1    | Information Security Policy | Applied       | GDPR compliance | ISO 27001:2022, GDPR |
| A.12.2.1   | Incident Management         | Not Applied  | Legacy systems lack integration | N/A |

Maintaining the SoA as a Living Document¶

The SoA must evolve with organizational changes, regulatory updates, and risk assessments. Key practices include:

1. Version Control and Audit Trails¶

Use version control systems (e.g., Git) to track changes.

Example command:

git commit -m "Updated SoA: Added A.14.1.1 for third-party risk management"

2. Scheduled Reviews¶

Conduct annual reviews aligned with management reviews and internal audits.

Example workflow:

[Risk Assessment] --> [SoA Update] --> [Management Approval] --> [Document Publication]

3. Automated Tools¶

Leverage compliance management platforms (e.g., SaaS solutions) to streamline updates and notifications.

Collaboration and Stakeholder Involvement¶

The SoA is a collaborative effort requiring input from:
- Risk owners (to justify control decisions).
- Legal/Compliance teams (to ensure regulatory alignment).
- IT and operational managers (to assess feasibility).
- Senior management (to approve high-level decisions).

Collaboration Diagram:
Visual diagram (e.g., UML or flowchart) recommended for clarity.

Integration with Other Processes¶

The SoA must align with:
1. Risk Assessments: Control decisions are based on identified risks.
2. Internal Audits: Verify compliance with applied controls.
3. Management Reviews: Ensure the SoA reflects strategic objectives.

Integration Flowchart:
Visual diagram (e.g., UML or flowchart) recommended for clarity.

Key takeaways¶

Structure: Use tables and clear sections to document control decisions and rationales.
Maintenance: Treat the SoA as a living document with version control and regular reviews.
Collaboration: Engage cross-functional teams to ensure alignment with risks, regulations, and business goals.
Integration: Link the SoA to risk assessments, audits, and management reviews for holistic compliance.