FAQ item index

Search every question across sub-FAQs

Find the exact question, open the source answer card, and copy a direct link to the anchored sub-FAQ response.

Indexed coverage
28of28items
Across 7 modules • Updated May 9, 2026
Author
Sorena AI
Published
May 9, 2026
Updated
May 9, 2026
Back to sub-FAQs
ISO/IEC 27001 SoA Exclusions

How should teams justify Statement of Applicability exclusions under ISO/IEC 27001?

Start with the operational decision: define what SoA Exclusions means in your ISO/IEC 27001 scope, who owns it, and what record proves the decision is current.

For ISMS work, keep the traceability chain visible: scope, risk, treatment choice, SoA entry, control owner, evidence sample, exception, corrective action, and management review decision. This keeps the answer useful in audits, customer reviews, incidents, supplier reviews, and management review.

  • Name the accountable owner and reviewer for SoA Exclusions.
  • Record the scope, assumptions, decision, approval date, evidence location, exception status, and next review trigger.
  • Escalate when SoA Exclusions changes risk acceptance, service commitments, customer promises, regulatory duties, or certification evidence.
Citations
ISO/IEC 27001:2022 standard page

Use this source as the governing requirements context for ISO/IEC 27001 scope, control governance, and review cadence in ISMS operations.

Jump to answerOpen module
ISO/IEC 27001 SoA Exclusions

What evidence should prove SoA Exclusions is current under ISO/IEC 27001?

The evidence should show the process operating. For this artifact, the strongest record usually includes ISMS scope, risk assessment, treatment plan, Statement of Applicability, Annex A evidence, internal audits, corrective actions, and management review records.

Avoid evidence that only repeats a requirement. A reviewer should be able to see the actual owner, date, system, supplier, security-critical system, service, incident, risk, or control sample behind the answer.

  • Use source records from the system of work, not screenshots created only for audit day.
  • Keep exceptions visible as risk acceptance, corrective action, or management-review input.
  • Update linked registers when the answer changes an owner, risk, control, service, supplier, or review date.
Citations
Jump to answerOpen module
ISO/IEC 27001 SoA Exclusions

Who should approve SoA Exclusions decisions under ISO/IEC 27001?

The person who can fund, operate, and correct the process should own the decision; governance should review consistency and exceptions.

For high-impact changes, approval should include the teams affected by the evidence: security, privacy, resilience, supplier management, security governance, legal, risk, or business service owners as relevant.

  • Use a named owner, named backup, and named escalation forum.
  • Separate preparation work from risk acceptance and final approval.
  • Keep approval records with the evidence rather than in disconnected email threads.
Citations
ISO/IEC 27001:2022 standard page

Use this source as the governing requirements context for ISO/IEC 27001 scope, control governance, and review cadence in ISMS operations.

Jump to answerOpen module
ISO/IEC 27001 SoA Exclusions

When should SoA Exclusions be reviewed under ISO/IEC 27001?

Review it at planned intervals and whenever the underlying scope, service, supplier, control, risk, security-critical system, personal data flow, incident process, or customer commitment changes.

A stale record is worse than a short record. If the facts change, update the evidence and mark what changed so the next reviewer can trust the page.

  • Set a planned review date and a change-trigger rule.
  • Use findings to update controls, procedures, contracts, risk registers, or training.
  • Carry unresolved items into management review or risk acceptance.
Citations
ISO/IEC 27001:2022 standard page

Use this source as the governing requirements context for ISO/IEC 27001 scope, control governance, and review cadence in ISMS operations.

Jump to answerOpen module
ISO/IEC 27001 Surveillance Audits

How should teams handle Surveillance Audits under ISO/IEC 27001?

Start with the operational decision: define what Surveillance Audits means in your ISO/IEC 27001 scope, who owns it, and what record proves the decision is current.

For ISMS work, keep the traceability chain visible: scope, risk, treatment choice, SoA entry, control owner, evidence sample, exception, corrective action, and management review decision. This keeps the answer useful in audits, customer reviews, incidents, supplier reviews, and management review.

  • Name the accountable owner and reviewer for Surveillance Audits.
  • Record the scope, assumptions, decision, approval date, evidence location, exception status, and next review trigger.
  • Escalate when Surveillance Audits changes risk acceptance, service commitments, customer promises, regulatory duties, or certification evidence.
Citations
ISO/IEC 27001:2022 standard page

Use this source as the governing requirements context for ISO/IEC 27001 scope, control governance, and review cadence in ISMS operations.

ISO/IEC 27006-1:2024 standard page

This source states that certification bodies audit and certify ISMS in accordance with ISO/IEC 27001 and supports the certification-body context for surveillance audits.

Jump to answerOpen module
ISO/IEC 27001 Surveillance Audits

What evidence should prove Surveillance Audits is current under ISO/IEC 27001?

The evidence should show the process operating. For this artifact, the strongest record usually includes ISMS scope, risk assessment, treatment plan, Statement of Applicability, Annex A evidence, internal audits, corrective actions, and management review records.

Avoid evidence that only repeats a requirement. A reviewer should be able to see the actual owner, date, system, supplier, security-critical system, service, incident, risk, or control sample behind the answer.

  • Use source records from the system of work, not screenshots created only for audit day.
  • Keep exceptions visible as risk acceptance, corrective action, or management-review input.
  • Update linked registers when the answer changes an owner, risk, control, service, supplier, or review date.
Citations
Jump to answerOpen module
ISO/IEC 27001 Surveillance Audits

Who should approve Surveillance Audits decisions under ISO/IEC 27001?

The person who can fund, operate, and correct the process should own the decision; governance should review consistency and exceptions.

For high-impact changes, approval should include the teams affected by the evidence: security, privacy, resilience, supplier management, security governance, legal, risk, or business service owners as relevant.

  • Use a named owner, named backup, and named escalation forum.
  • Separate preparation work from risk acceptance and final approval.
  • Keep approval records with the evidence rather than in disconnected email threads.
Citations
ISO/IEC 27001:2022 standard page

Use this source as the governing requirements context for ISO/IEC 27001 scope, control governance, and review cadence in ISMS operations.

Jump to answerOpen module
ISO/IEC 27001 Surveillance Audits

When should Surveillance Audits be reviewed under ISO/IEC 27001?

Review it at planned intervals and whenever the underlying scope, service, supplier, control, risk, security-critical system, personal data flow, incident process, or customer commitment changes.

A stale record is worse than a short record. If the facts change, update the evidence and mark what changed so the next reviewer can trust the page.

  • Set a planned review date and a change-trigger rule.
  • Use findings to update controls, procedures, contracts, risk registers, or training.
  • Carry unresolved items into management review or risk acceptance.
Citations
ISO/IEC 27001:2022 standard page

Use this source as the governing requirements context for ISO/IEC 27001 scope, control governance, and review cadence in ISMS operations.

Jump to answerOpen module
Page 2 of 2
Previous12Next