SEF-07 — Security Breach Notification

Every framework that asks this

Answer SEF-07 once and it typically satisfies the equivalent control elsewhere. Altitude and confidence vary — a domain-level anchor is a starting point to verify, not an audited equivalence.

Full provenance and NIST 800-53 mappings: the framework crosswalk.

What the reviewer is really checking

The reviewer is establishing whether a breach at your company becomes a controlled, communicated event for them, or a surprise they learn about from a regulator or the news. They test three layers. First, that a real incident-response capability exists: a documented plan with defined roles (who declares an incident, who leads, who communicates), severity classification, and containment, eradication, and recovery steps, not a paragraph in a policy nobody has run. Second, that it has been exercised: reviewers look for the date of your last tabletop or simulation, because an untested plan tends to fail on first contact. Third, and this is the leg that decides deals, a customer-notification commitment: whether you will notify affected customers, who triggers it, and within what timeframe, often 72 hours mirroring GDPR Article 33, or whatever your contracts commit to. Frameworks encode all three: NIST SP 800-53 IR and NIST SP 800-61 cover the lifecycle, SOC 2 CC7.3 to CC7.5 test detection through recovery, and ISO 27001 A.5.24 to A.5.28 cover planning, response, and learning. The reviewer is checking that these will hold under a real incident and that the notification clause is a commitment, not an aspiration, because their own regulatory and contractual obligations depend on yours.

What a truthful, defensible answer contains

A defensible answer describes a documented incident-response plan and names its roles: who can declare an incident, an incident commander or lead, and a communications owner. It states how incidents are classified by severity and outlines the lifecycle you follow: detection and triage, containment, eradication, recovery, and post-incident review. It gives the date, or the cadence, of your most recent tabletop or exercise, because that is the evidence the plan is live. Most importantly it states a customer-notification commitment: the condition that triggers notification, for example confirmed unauthorized access to customer data, who is accountable for sending it, and a specific timeframe, expressed as a defined SLA or contractual window rather than 'promptly.' Where the timeframe depends on the contract or applicable law, a truthful answer says so and points to where the commitment is written. It should map to the referenced control (CCM SEF, SOC 2 CC7.3–CC7.5, ISO 27001 A.5.24–A.5.28) and be honest about maturity: if tabletops are new or notification SLAs vary by tier, state that rather than implying a uniform guarantee. The aim is to let the reviewer see a process that would actually run and a notification clause they can hold you to.

Make it traceable

Anchor each layer to an artifact. Point 'we have a plan' at the incident-response plan or policy document, with version and owner; 'roles are defined' at the RACI or the plan's roles section; 'it's tested' at the after-action report or exercise record with its date; and 'we'll notify you' at the specific contract clause or DPA section stating the timeframe, not a sentence composed for this questionnaire. If a SOC 2 report tests your incident controls, cite CC7.3 to CC7.5 and the report date so the buyer sees a third party examined them. The strongest version quotes the notification window from the exact document that binds you (MSA or DPA §X) so the reviewer can confirm the commitment survives after the deal closes. Every claim should resolve to something you could attach, and the attachment should say the same thing on the day an incident occurs.

Answer patterns that hold up

• Plan, then roles, then severity model, then lifecycle, then notification commitment: each clause names a mechanism or document, not an adjective.
• Notification stated as trigger condition, then accountable owner, then specific timeframe, then where it's written (DPA/MSA §X).
• Last-exercised date (or cadence) stated explicitly as evidence the plan is live.
• Timeframe expressed as a defined SLA or contractual window, never 'promptly' or 'as soon as possible.'
• A maturity boundary stated where notification SLAs vary by tier or contract.

Evidence that backs the answer

Red flags reviewers catch

• An incident-response plan described with no customer-notification timeframe at all.
• Notification promised 'promptly' or 'without undue delay' with no SLA, trigger, or contract reference.
• A plan with no last-tested date, implying it has never been exercised.
• Roles left generic ('the security team handles it') with no named incident commander or communications owner.
• The answer conflates internal detection with external notification, so the buyer can't tell when they'd hear.

Sources

• CSA Cloud Controls Matrix (CCM) v4 — SEF domain
• NIST SP 800-53 Rev. 5 — IR (Incident Response) family
• AICPA Trust Services Criteria (SOC 2) — CC7.3–CC7.5
• ISO/IEC 27001:2022 — A.5.24–A.5.28 Information security incident management

Other Security Incident Management, E-Discovery, & Cloud Forensics controls