1. Describe the organization before opening the questionnaire
Gather the units, processes, locations, systems, third parties and owners included in the review. The general context can be reused in new audits, so write it in operational terms rather than marketing language.
- Which entity or unit is in scope
- Which processes support the service and where they run
- Who answers, reviews and approves exceptions
2. Separate applicable, not applicable and out of scope
Review the framework before answering it and classify every control. Out-of-scope is not missing evidence: it is a decision supported by a concrete reason, such as the service model, location or absence of a technology.
- Applicable: it will be assessed and needs an answer or evidence
- Not applicable: the organization can explain why it does not apply
- Out of scope: it is excluded by the boundaries of this audit
3. Write the rationale for every exclusion
Avoid generic reasons such as ‘not applicable’. Explain which business fact supports the exclusion and who validated it. The rationale travels with the result and export instead of disappearing when ownership changes.
4. Confirm scope with the right people
Before requesting documents, share the control list with people who know operations, security and legal requirements. Early review prevents evidence work on controls that will later be removed, or missing a critical process.
5. Use scope as the re-audit baseline
When you reassess, keep the context and boundaries used before and compare like with like. If the organization, service or framework changed, record that change before interpreting score evolution.
- Do not change scope to make the score look better
- Exclusions remain auditable
- Human review decides whether an answer becomes compliant