Drafting the Statement of Applicability in Your Own Words

This lesson shifts from understanding the SOA concept to actually drafting it for your organisation. The goal is to write an SOA that is clear, specific to your situation, and defensible during audit.

The SOA Format

Most organisations use a simple table format with columns: Control Number, Control Name, Applicable (Yes/No), Rationale/Implementation Notes. Some organisations add additional columns for responsibility, implementation status, or target implementation date. The format is less important than the content. What matters is that auditors can quickly find each control and understand your position on it.

A completed section of an SOA might look like this:

5.1.1 AI governance scope: Yes. Our scope includes all production AI systems operated by data science and customer analytics teams.

5.2.1 AI governance structure and responsibilities: Yes. We have an AI Governance Committee (Chief Data Officer, VP Engineering, Compliance Lead, Legal Counsel) that meets monthly. Each system owner is assigned and documented.

5.3.1 Competence needs identification: Yes. We have defined competence profiles for each AI governance role. Annual competence assessments are conducted.

6.1.2 Process for identifying and managing opportunities: No. Our organisation is not large enough to allocate formal resources to opportunity identification beyond what occurs in risk assessment discussions.

Writing Rationale That Works

For “No” entries, your rationale is critical. Good rationales explain your organisation’s size, complexity, risk profile and constraints. They also often explain how you address the underlying governance need through alternative means.

Example of a strong rationale: “Control 8.3.2 (Monitoring of third-party models): Not applicable. Our organisation does not currently use third-party models from external vendors. All models are developed internally. If we adopt third-party models, we will implement this control.”

Example of a weak rationale: “We do not have time for this.” This does not explain why the control is not applicable to your situation.

Building on Your Risk Assessment

Your SOA should reference your risk assessment. If you have identified a specific risk, you should show a control that addresses it in your SOA. Conversely, if you have selected a control, you should be able to point to a risk that justified selecting it. This traceability is what auditors look for.

For example, if your risk assessment says “Risk: Our models may degrade over time due to data drift. Likelihood: Medium. Impact: High. Control: Monthly performance monitoring.” Then your SOA should include a control on monitoring (probably control 9.1.1 or similar) with an implementation note that references your monthly monitoring process.

Demonstrating Proportionality

Your SOA should demonstrate that your control coverage is proportionate to your organisation’s size and complexity. Auditors understand that a startup with three people working on AI will have a different control set than a bank with a hundred-person AI team.

If you are a small organisation, you might justify lower intensity controls by noting, “Our small team size and close coordination means that many oversight activities that require formal documentation in larger organisations occur through daily interaction and direct communication. We have documented our lightweight processes as our equivalent of formal governance.”

Including Implementation Details

For “Yes” entries, you can optionally add implementation details. This is helpful because it makes the SOA a reference for how controls are actually executed.

Example: “8.1.1 Data governance objectives and processes: Yes. We maintain a data governance policy that defines data quality standards for each dataset. The data steward conducts quarterly data quality reviews. Data quality metrics are tracked and reported to the governance committee quarterly.”

Consistency Across Entries

Read through your completed SOA to check for internal consistency. If you have excluded control 6.1.2 (opportunity identification), but you have included control 9.3.1 (management review), auditors might expect your management review to include consideration of opportunities. Make sure your exclusions and inclusions align logically.

Sectioning by Area

Many organisations section their SOA by Annex A category: Governance (5.x controls), Human and Organisational (6.x), Data Governance (7.x), Information Security (8.x), and so on. This makes it easier for readers to navigate and for auditors to reference during audit interviews.

Signature and Version Control

Treat your SOA like any controlled document. Include a version number, date, and sign-off by someone with authority (often the AI Governance Lead or Chief Data Officer). If your SOA changes, update the version and document what changed. This version control demonstrates that you treat the SOA seriously and maintain it carefully.

SOA as Communication Tool

Beyond audit, your SOA is an internal communication tool. It tells everyone in the organisation what controls are in place and who is responsible. New team members can read the SOA to understand the organisation’s AI governance framework. System owners can reference it to know what they are expected to implement.

A well-written SOA is one of the most valuable documents in your ISO 42001 implementation. It crystallises your governance choices and provides the foundation for operational implementation.