Use Case

Breach notification and regulator readiness
one engagement record across every notification clock

Most security organisations operate breach notification as a series of last-minute decisions across email, chat, and a legal-team Word document. The clocks (GDPR 72 hours, NIS2 24 and 72 hours, SEC four business days, HIPAA 60 days, DORA initial and intermediate windows, state law variations, PCI DSS account data compromise rules) keep running while the disclosure committee reconstructs what was known, when it was known, and who decided what. Run breach notification and regulator readiness as a structured workflow on one engagement record so every notification clock, materiality determination, evidence artefact, and disclosure decision lands on the same trail the regulator, the auditor, and the audit committee can read against later.

Get Started Free

No credit card required. Free plan available forever.

Run every notification clock and disclosure decision on one engagement record

Breach notification and regulator readiness is where most security organisations discover that their incident programme was not, in fact, an integrated programme. The 72-hour GDPR clock runs in counsel email. The four-business-day SEC clock runs on a disclosure-committee Word document. The customer notification queue runs in marketing tools. The state breach notification deadlines run on a side spreadsheet a legal paralegal pieced together. When a regulator inquiry six months later asks who knew what, when, and what was decided, the answer is a multi-week reconstruction across half a dozen channels. Run every notification clock, materiality determination, evidence artefact, and disclosure decision on one engagement record so the chronology of the response, the chain of decisions, and the custody of artefacts can be read as a single trail.

This workflow composes with the rest of the security operating model. The technical response that produces the forensic timeline runs on the incident response workflow. The product-security-side response that handles vulnerability disclosure to coordinated parties runs on the PSIRT workflow. The zero-day-driven emergency response loop sits on the zero-day and emergency response workflow. The cyber-insurance evidence chain that the breach feeds into rides on the cyber insurance evidence workflow. The retention discipline that governs the post-event evidence pack lands on the audit evidence retention and disposal workflow.

Eight regulator clocks the workflow has to track in parallel

A modern breach often touches several regulator regimes at once. The clocks run in parallel, on different start conditions, with different deadlines and different evidence expectations. The engagement holds every applicable clock as an explicit object so the most-restrictive-clock-wins public posture does not obscure the per-regime filing discipline each statute still demands.

Regime	Clock and obligation	Operating note
GDPR Article 33 (EU/EEA, UK GDPR mirror)	72 hours from awareness of a personal data breach for notification to the supervisory authority. Communication to data subjects without undue delay where the breach is likely to result in a high risk to rights and freedoms (Article 34).	Reasoned delays beyond 72 hours have to be documented with explanation. Awareness is when the controller has reasonable certainty that a security incident has led to personal data being compromised.
NIS2 Article 23 (EU essential and important entities)	Early warning to the competent authority or CSIRT within 24 hours of awareness, incident notification within 72 hours, intermediate report on request, and a final report within one month.	Significant incidents are defined by operational disruption, financial loss, or impact on natural or legal persons. The clocks layer on top of any GDPR clock when personal data is also affected.
SEC Item 1.05 of Form 8-K (US public registrants)	Form 8-K filing within four business days of materiality determination. Item 1.05(c) requires amendment when material information becomes available. Item 1.05(d) provides a narrow law-enforcement delay where disclosure would substantially harm public safety or national security.	The clock starts on materiality determination, not on incident discovery. The detection-vs-determination two-clock discipline is core to operating the rule defensibly.
HIPAA Breach Notification Rule (US healthcare)	Notification to affected individuals without unreasonable delay and within 60 days of discovery. HHS notification within 60 days for breaches of 500 or more individuals; annual report for smaller breaches. Media notice for breaches of 500 or more in a state or jurisdiction.	Discovery is when the breach is known or, by exercising reasonable diligence, would have been known. Business associate breaches trigger notification to the covered entity which then runs its own clock.
DORA Articles 19 and 20 (EU financial entities)	Initial notification of major ICT-related incidents to the competent authority within the regulator-prescribed window, intermediate reports as the response progresses, and a final report on resolution. Voluntary notification of significant cyber threats is also contemplated.	DORA layers on top of national supervisory regimes (FCA, BaFin, ACPR, AFM, CSSF, CONSOB) and may concur with the NIS2 regime where the entity is dual-classified.
PCI DSS account data compromise	Immediate notification to acquirers, payment brands, and where applicable card schemes following an account data compromise. The brand-specific Account Data Compromise (ADC) processes set the operational cadence and forensic investigator (PFI) engagement.	Compromise notification is contractual rather than regulatory in many jurisdictions. The PCI Forum guidance and brand-specific ADC manuals set the workflow the merchant or service provider has to operate against.
US state breach notification laws	Each US state operates its own breach notification statute with deadlines ranging from "as expediently as possible without unreasonable delay" to fixed-day windows (often 30, 45, or 60 days). Many states require attorney-general notification above a threshold count and substitute notice provisions for large-volume breaches.	Multi-state breaches require parallel jurisdiction-by-jurisdiction tracking. Most-restrictive-clock-wins is a common operating discipline, but the per-state evidence still has to be filed against each statute the breach touches.
Sector-specific and contractual	Banking regulators (OCC, Fed, FDIC, FCA), insurance regulators (NAIC Model Law), telecommunications regulators (FCC), critical-infrastructure regimes (NCSC CAF, CISA), and customer contracts (MSAs, DPAs, BAAs) frequently set additional notification windows that run alongside the statutory clocks.	Contractual customer notice is often the largest queue by volume and the one that drives the public posture. The engagement record holds every contract-driven clock alongside the statutory ones so the queue does not depend on a single counsel knowing every contract.

Six failure modes that quietly break breach notification programmes

Most breach notification failures do not look like failures while they are happening. They look like sensible defaults: track the clock in counsel email, decide materiality once, keep notification drafts in a shared drive. The cost arrives months later as a missed amendment, an inconsistent customer message, or an evidence chain that cannot answer a regulator inquiry.

Notification clocks run in email, not on a record

The 72-hour GDPR clock and the four-business-day SEC clock run in parallel, but each is tracked in a separate counsel email thread. When the incident commander rotates, the new commander reconstructs the deadlines from forwarded chat. A clock missed because nobody was named the owner is not defensible to a supervisory authority.

Materiality is decided once and never amended

The disclosure committee renders an initial materiality determination at hour twelve of the incident based on the data available then. New forensic findings at hour seventy expand the scope, but the determination is never revisited. SEC Item 1.05(c) requires amendment when material information becomes available; the missed amendment is the failure mode that surfaces in litigation.

Notification artefacts lose custody chain

Draft notifications, regulator submissions, and customer letters live in a shared drive without retention class, named author, named approver, or timestamps. When a regulator inquiry six months later asks who approved the disclosure language and on what basis, the engagement cannot show the chain. The disclosure was correct; the closure record is missing.

Multi-jurisdiction notification collapses to one filing

A multi-state breach gets one substitute-notice press release and one combined regulator letter. Several states required attorney-general notification with a specific format and deadline that the combined approach missed. The state-by-state filing discipline is the difference between the breach being closed in seventy-two hours and the company carrying open enforcement matters in five jurisdictions for two years.

Counsel privilege is asserted too broadly or too narrowly

Either every artefact gets stamped attorney-client privileged regardless of whether counsel directed the work, or no artefact carries the privilege flag and the disclosure committee has no clean read on what is privileged work product. The engagement record needs explicit privilege flags per artefact, set by counsel at capture, so the production response to a regulator subpoena or a litigation hold can be filtered without a multi-week privilege review.

Customer notifications run in marketing, not in the breach engagement

Customer notification volume often dwarfs regulator notification volume. When the customer queue runs in a marketing-tools workflow disconnected from the breach engagement, the segmentation, the messaging variants, the open and bounce tracking, and the holdback decisions for unconfirmed customer cohorts are not visible to the disclosure committee. Inconsistent customer messaging is one of the largest sources of post-breach reputational damage.

Six fields every materiality determination has to record

A defensible materiality determination is six concrete fields on the engagement, not a narrative paragraph in a counsel email. The fields make the determination chronology reconstructable when a regulator or a litigant asks how the company reached the conclusion it disclosed.

Regime and clock identifier

Each determination records the regulator regime it speaks to (GDPR, NIS2, SEC, HIPAA, DORA, state law by jurisdiction, sector regulator, contractual obligation), the specific article or rule, the clock identifier, and the start condition that triggered the clock (incident discovery, awareness, materiality determination, contractual trigger).

Criteria applied and underlying evidence

The criteria the disclosure committee applied to the determination (financial impact, operational disruption, reputational impact, legal liability, customer harm, sector-specific factors, regulatory definition of significant incident or material cybersecurity incident) and the evidence references the determination read against (forensic memos, finding identifiers, log excerpts, third-party assessments, business-impact analysis). The engagement holds the evidence; the determination cites the references.

Named decider, dissent, and timestamp

The named decider for the determination (typically the disclosure committee chair, the general counsel, or the CISO depending on the regime), any dissenting views captured during the deliberation, the deliberation duration, and the determination timestamp. Dissent is not a failure to record; it is the artefact that demonstrates the deliberation was substantive when a regulator asks how the determination was reached.

Reasoned conclusion and notification trigger

The conclusion the determination reached (notify, do not notify, notify with reasoned delay, defer pending further evidence) and the notification queues the conclusion triggers (which regulators, which customer cohorts, which contractual partners, which insurer, which board read-out cadence). The conclusion is the routing instruction the parallel notification queues read against.

Re-evaluation triggers and amendment chronology

The named re-evaluation triggers that would reopen the determination (new forensic finding, scope expansion, re-classification of affected data, regulator request for additional information, public disclosure by a third party). Each re-evaluation produces a fresh determination on the engagement rather than editing the prior one, so the chronology is reconstructable and the SEC Item 1.05(c) amendment cadence has a clean trail.

Privilege flag and disclosure scope

The attorney-client privilege flag set by counsel at capture, the work-product doctrine flag where applicable, and the disclosure scope the determination authorises (privileged-internal-only, regulator-disclosable, public-statement, customer-notification). The privilege filter is what the production response to a regulator subpoena or a litigation hold reads against.

Parallel notification queues the engagement runs concurrently

During an active breach the engagement runs eight queues in parallel. Each queue has a named owner, a documented cadence, and an unresolved-item escalation rule so deadlines do not drift.

Regulator notification queue, one row per applicable jurisdiction, with the clock, the named owner, the submission status, and the regulator portal or email path.
Customer and individual notification queue, with templating per cohort, segmentation, holdback rules for unconfirmed cohorts, and bounce or undeliverable tracking.
Law-enforcement coordination queue, with the named contact at FBI, NCA, Europol, or regional CERT, the case reference, and the disclosure-delay request status where Item 1.05(d) or analogous provisions apply.
Insurer and broker notification queue, with the cyber-policy notice-of-claim window, the broker contact, the carrier panel-counsel assignment, and the policy-limit posture.
Board and audit-committee briefing queue, with the materiality reads, the meeting cadence (initial briefing, follow-up cadence, audit-committee deep dive), and the briefing artefact references.
Contractual partner notification queue, with the contract reference, the notification window, the named partner contact, and the receipt acknowledgement.
Internal communication queue, with employee notification timing, leader briefings, and the cross-departmental coordination that prevents accidental disclosure outside the controlled cadence.
Public statement queue, with the press-release draft, the website disclosure page, the social-channel statement, and the holdback decisions for non-public phases.

How breach notification and regulator readiness runs in SecPortal

Breach notification rides on the same feature surfaces the rest of the security programme already uses. The breach opens as an engagement on the workspace, every state change captures into the activity log, document management holds the notification artefacts with custody chain, and AI report generation composes the disclosure narrative from the live record so the audit committee, the board, and the regulator inquiry response all read against one record.

Breach as an engagement

The breach opens on the engagement record with the named incident commander, legal counsel, disclosure committee chair, and privacy officer. Discovery timestamp, in-scope assets, jurisdictions, and data categories all live on the engagement.

Regulator clock map

The applicable clocks (GDPR, NIS2, SEC, HIPAA, DORA, state law, PCI DSS, contractual) are recorded as explicit objects with start condition, deadline, owner, and reset triggers. Most-restrictive-clock-wins is a public-posture default; the per-regime filing still runs against each statute.

Materiality decision register

Each determination logs as a structured row with regime, criteria, evidence references, decider, dissent, timestamp, conclusion, and privilege flag. Re-evaluations produce fresh rows; nothing is edited in place so the chronology is reconstructable.

Notification artefact custody

Engagement document management holds notification drafts, regulator submissions, customer letters, and counsel-reviewed evidence. Retention class is stamped at capture; named author, reviewer, and approver attach to every artefact.

Findings tied to determinations

Findings management captures every forensic evidence row with severity and evidence reference. The materiality determination cites finding identifiers so the disclosure rests on verifiable evidence rather than narrative recall.

AI disclosure narrative

AI report generation composes the disclosure narrative for the audit committee, the board read-out, and the regulator inquiry response from the live record. Reports regenerate so the privileged view and the regulator-disclosable view never disagree about the underlying chronology.

RBAC across the disclosure committee

Team management scopes engagement access to counsel, the disclosure committee, security operations, GRC, and executive leadership. Privilege-flagged artefacts are isolated from broader workspace roles by access scoping.

MFA across the workspace

Multi-factor authentication is enforced for every workspace user. The breach engagement does not relax access control; the response and the disclosure run inside the same access posture as steady-state.

Activity log and notifications

The activity log captures every state change with timestamp and user attribution. The CSV export becomes the audit and inquiry-response evidence chain. Notifications surface unresolved queue items before deadlines drift.

Five reconciliation views the breach engagement actually drives

The reads that drive breach work are not the static disclosure deck and the static post-mortem brief. They are the live views the disclosure committee, the closing legal team, and the regulator-relations team use between meetings. The five below are the ones every meaningful breach engagement settles on, and they all derive from the live engagement record rather than a parallel spreadsheet extract.

Open clocks by deadline

Every applicable regulator and contractual clock with the open deadline, the named owner, the submission status, and the reset trigger history. The view the disclosure committee chair reads against the calendar.

Materiality determination chronology

Every determination row with regime, criteria, evidence references, decider, dissent, conclusion, and timestamp. The view the audit committee reads to understand how the determination evolved as the response progressed.

Notification queue execution

Every queue (regulator, customer, law-enforcement, insurer, board, contractual, internal, public) with named owner, cadence, items in flight, items closed, and bounce or undeliverable counts. The view the operations lead carries into the daily standup.

Artefact custody and privilege filter

Every notification artefact with named author, reviewer, approver, retention class, and privilege flag. The view the legal team reads when a regulator subpoena or a litigation hold lands and the production response has to be filtered cleanly.

Activity log export

Every state change across the active phase, the amendment phase, and the regulator inquiry phase with timestamp and user attribution. The CSV export is the evidence trail behind the disclosure narrative, ready for ISO 27001, SOC 2, NIST, PCI DSS, HIPAA, NIS2, and DORA audit reads.

What auditors and supervisory authorities expect

Breach notification work shows up in audit reads whenever an external assessor reviews incident management or whenever a supervisory authority opens an inquiry. The frameworks below all expect evidence that covers the response chronology, the determination register, the notification queues, and the artefact custody chain.

Framework	What the audit expects
ISO 27001:2022	Annex A 5.24 (information security incident management planning and preparation), 5.25 (assessment and decision on information security events), 5.26 (response to information security incidents), 5.27 (learning from information security incidents), and 5.28 (collection of evidence) cover the breach response and the supporting evidence chain. Annex A 5.34 (privacy and protection of PII) and 5.33 (protection of records) cover the notification artefacts. The engagement record holds the determination chronology, the notification queues, the artefact custody, and the activity log so the surveillance audit reads one trail rather than three.
SOC 2 Trust Services Criteria	Common Criteria CC2.x (communication and information), CC3.x (risk assessment), CC7.3 (the system is monitored to identify anomalies), CC7.4 (security incident management), and CC7.5 (recovery and lessons learned) cover the breach lifecycle. Privacy criteria (where the report scope includes Privacy) cover the disclosure to affected individuals. The engagement record produces the evidence the auditor reads when asking how the entity identified, classified, escalated, and disclosed the incident.
NIST SP 800-61 and SP 800-53	SP 800-61 Rev 2 (Computer Security Incident Handling Guide) sets the four-phase model the response operates against. SP 800-53 controls IR-2 (training), IR-3 (testing), IR-4 (incident handling), IR-6 (incident reporting), IR-8 (incident response plan), and AU-6 (audit record review and analysis) cover the operating discipline. The engagement record carries the response chronology, the determination register, and the notification queues against these controls.
NIST CSF 2.0	The RESPOND function (RS.MA, incident management; RS.AN, incident analysis; RS.CO, incident communication; RS.MI, incident mitigation; RS.RP, incident reporting) and the RECOVER function (RC.RP, recovery planning; RC.IM, incident recovery activities; RC.CO, incident recovery communications) are the framework backbone the breach engagement produces evidence against. The GOVERN function (GV.PO, policy; GV.OC, organisational context) is what the materiality determination and the regulator-clock map sit inside.
PCI DSS v4.0	Requirement 12.10 (incident response plan), 12.10.1 (plan documentation), 12.10.2 (plan testing), 12.10.3 (designated personnel), 12.10.4 (training), 12.10.5 (alerting), 12.10.6 (lessons learned), and 12.10.7 (procedures for responding to suspected or confirmed account data compromises) are the QSA reads. The engagement record holds the response chronology, the brand and acquirer notifications, and the PFI engagement evidence the QSA reads against.
HIPAA Security Rule and Breach Notification Rule	164.308(a)(6) (security incident procedures), 164.308(a)(7) (contingency plan), 164.402 (breach definition and risk assessment factors), 164.404 (notification to individuals), 164.406 (media notice for breaches of 500 or more in a state or jurisdiction), 164.408 (notification to HHS), and the four-factor risk assessment all read against the engagement evidence chain. The OCR breach portal submission and the documentation supporting the unsecured-PHI determination both live on the engagement.
NIS2 Directive and DORA	NIS2 Article 23 (incident notification, including the 24-hour early warning, 72-hour incident notification, and one-month final report) and DORA Articles 19 and 20 (major ICT-related incident reporting, the initial-intermediate-final cadence, and the threat intelligence-sharing posture) are the regulator reads. The engagement record holds the regulator-clock map, the artefact custody, and the inquiry response chain so the supervisory authority reads a coherent file rather than a sequence of forwarded communications.

Where breach notification sits in the rest of the security operating model

Breach notification is a structured workflow that composes with the rest of the security programme. The technical response feeds the determination register; the determination register drives the notification queues; the notification artefacts feed the regulator inquiry response; the post-event evidence pack rolls into the audit and assurance cycle.

Upstream and adjacent

The technical response runs on the incident response workflow and the zero-day response workflow. The product-side coordinated response runs on the PSIRT workflow. The cyber-insurance evidence chain rides on the cyber insurance evidence workflow.

Downstream and reporting

The post-event evidence pack rides on the audit evidence retention and disposal workflow. The leadership read-out lands on the security leadership reporting workflow. Cross-framework evidence reuse runs on the control mapping crosswalks workflow.

Pair the workflow with the long-form guides and the framework references

Breach notification is operational. The surrounding long-form guides explain the broader operating model and the rule-by-rule expectations the workflow has to satisfy. Pair this workflow with the SEC cybersecurity incident materiality guide for the Item 1.05 trigger and amendment cadence, the incident response plan guide for the response operating model, the incident response tabletop exercise guide for the rehearsal discipline that exposes notification gaps before a live event, the board-level security reporting guide for the audit-committee read-out structure, and the enterprise incident response at scale guide for the multi-team coordination patterns. The framework references that mandate breach notification evidence include the ISO 27001 framework page, the SOC 2 framework page, the NIS2 framework page, the DORA framework page, the HIPAA framework page, the GDPR framework page, the PCI DSS framework page, and the SEC cybersecurity disclosure rule page.

Buyer and operator pairing

Breach notification and regulator readiness is the workflow CISOs chair as the security-side input into the disclosure committee, GRC and compliance teams run as the regulator-evidence backbone, internal security teams run as the operational chronology, security operations leaders run for queue execution and pacing, and vulnerability management teams contribute the finding-level evidence the materiality determination reads against.

What good breach notification and regulator readiness feels like

Every clock has a named owner

No clock runs in counsel email. The disclosure committee chair, the privacy officer, and the named regime-specific filer all read the same clock list, with the same deadlines, against the same calendar.

Determinations evolve as a chain

Materiality is not decided once. New forensic findings produce fresh determinations on the engagement; the chronology is reconstructable as the chain of decisions the disclosure committee actually rendered, not as the final disclosure read backwards.

Customer messaging stays consistent

The customer queue runs on the breach engagement alongside the regulator queues. The disclosure committee can answer when each cohort was notified and what they were told, and the messaging across email, in-app, and statutory postal mail stays consistent.

Audit reads from one record

The determination chronology, the notification artefacts, the queue execution, the inquiry responses, and the activity log all read from the same engagement. ISO 27001, SOC 2, NIST, PCI DSS, HIPAA, NIS2, and DORA assessors get the evidence as a query rather than a multi-week reconciliation sprint.

Breach notification and regulator readiness is the structured workflow the disclosure committee, the legal team, the security operations team, and the GRC team all read against. Run it on one engagement record so every notification clock, every materiality determination, every artefact, and every disclosure decision lives on a single trail rather than scattered across counsel email, marketing tools, and a side spreadsheet.

Frequently asked questions about breach notification and regulator readiness

What is breach notification and regulator readiness as a workflow?

Breach notification and regulator readiness is the structured operating discipline that runs every notification clock, materiality determination, evidence artefact, and disclosure decision against a single engagement record from the moment a triggering event is suspected through the closure of regulator inquiries and the post-event programme retrospective. The workflow exists because most regulator regimes (GDPR Article 33, NIS2 Article 23, SEC Item 1.05, HIPAA, DORA, state law, sector-specific) layer on each other, run on different start conditions and different deadlines, and demand different evidence. Operating each in a separate channel produces missed clocks, inconsistent disclosures, and an evidence chain that cannot be reconstructed during a regulator inquiry six months later.

How does this differ from incident response?

Incident response covers the technical containment, eradication, recovery, and lessons-learned loop. Breach notification and regulator readiness covers the disclosure decisions and regulator-facing evidence that sit on top of the incident response chronology. The two are tightly coupled: forensic findings during incident response feed the materiality determination; the determination drives the notification queues; the notification artefacts feed the regulator inquiry response. Run incident response on the same engagement as breach notification so the technical timeline and the disclosure timeline are queryable from one record rather than reconciled across two.

How do you operate multiple regulator clocks in parallel?

Each applicable clock is recorded explicitly on the engagement at the moment a triggering event is suspected, with the start condition, the regulator regime, the article or rule, the deadline, the named owner, and the reset triggers. The most-restrictive-clock-wins discipline is a useful default for the public posture, but the per-regime evidence still has to be filed against each statute the breach touches. A multi-state US breach with EU/EEA cross-border data exposure can carry GDPR, NIS2 (where the entity is dual-classified), SEC (if a public registrant), HIPAA (if covered entity or business associate), DORA (if a financial entity), state law in every affected jurisdiction, PCI DSS account data compromise (if cardholder data is in scope), and contractual customer notification all simultaneously. The parallel-queue model is what keeps each clock owned and visible.

What is the materiality determination and why is it a decision register?

Materiality determination is the disclosure committee judgment that a triggering event meets the regulatory threshold for notification under a specific regime (or, for SEC Item 1.05, that a cybersecurity incident is material to a reasonable investor). It is rendered as a decision register rather than a single document because regulators and litigants will later ask not only what was disclosed but when, by whom, on what evidence, with what dissenting views, and how the determination evolved as the response progressed. Each determination logs the regime, the criteria applied, the evidence references, the named decider, the dissent, the timestamp, the conclusion, and the privilege flag. When new evidence arrives, a fresh determination is logged rather than the prior one being edited.

How does this workflow handle attorney-client privilege?

Privilege has to be set by counsel at capture, not asserted broadly across every artefact later. The engagement records the privilege flag (attorney-client, work-product doctrine, neither, joint-defence) per artefact, the counsel who set the flag, and the timestamp. When a regulator subpoena or a litigation hold lands, the production response is filtered against the privilege flags rather than re-reviewed artefact by artefact. Over-broad privilege assertion fails because regulators will challenge the assertion; under-asserted privilege fails because protected work product becomes discoverable. The discipline is per-artefact privilege capture at the moment of creation.

How do you avoid the SEC Item 1.05(c) amendment failure?

Item 1.05(c) requires a Form 8-K amendment when material information that was not determined or unavailable at the time of the original filing becomes available. The failure mode is treating the original filing as a closed matter. The engagement keeps the open-loop register: every fact pattern the original filing did not address (forensic timeline elaborations, scope expansions, attribution updates, financial-impact revisions, regulator coordination outcomes) is tracked as an open loop with a named owner, a re-evaluation cadence, and an explicit close condition. When a loop closes with material information, the amendment is filed and the loop closure timestamp lands on the engagement. Loops without material outcomes close with a no-amendment-required note and the same timestamp discipline.

How does customer notification fit into the workflow?

Customer notification is typically the largest queue by volume and the queue that most directly drives reputational damage when handled inconsistently. The breach engagement holds the customer notification queue alongside the regulator queues so the segmentation (which customers, in which order, with which messaging variant), the holdback rules for unconfirmed cohorts, the templating, the bounce and undeliverable tracking, and the cross-channel timing (email, in-app, postal mail where statute requires it) are all visible to the disclosure committee. Running the customer queue in a marketing-tools workflow disconnected from the breach engagement is a common failure mode because the disclosure committee then cannot answer when each cohort was notified and what they were told.

How does SecPortal support breach notification and regulator readiness?

The breach opens as a dedicated engagement on the workspace with the suspected event, the discovery timestamp, and the named incident commander, legal counsel, disclosure committee chair, and privacy officer. Findings management captures every piece of forensic evidence as a finding with severity, evidence reference, and the regime tags the determination reads against. Document management holds notification drafts, regulator submissions, customer letters, and counsel-reviewed evidence with retention class stamped at capture. The activity log captures every state change with timestamp and user attribution. AI report generation produces the disclosure narrative for the audit committee, the board read-out, and the regulator inquiry response from the live record. Team management with RBAC scopes engagement access (counsel, security operations, GRC, executive leadership) and multi-factor authentication is enforced across the workspace. The engagement stays open through the amendment phase, the regulator inquiry phase, and the post-event retrospective so the chain from triggering event to closure reads as one record.

Does SecPortal file regulator notifications automatically?

No. SecPortal does not submit regulator filings automatically, sign Form 8-K filings, transmit to the OCR breach portal, post to the ICO online form, send to the BaFin, or operate any direct regulator API integration. Each filing is the responsibility of named counsel and the named filing officer for the regime in question. SecPortal holds the determination chronology, the notification artefacts, the queue execution log, and the evidence custody chain so the named filer has a single record to draft against and the disclosure committee has a single record to approve from. The platform is the evidence backbone, not the filer of record.

How long does a breach engagement typically stay open on SecPortal?

The active phase typically runs from the moment of triggering event through the initial round of regulator and customer notifications, often a few days to several weeks depending on the regime mix. The amendment phase covers SEC Item 1.05(c) updates, NIS2 intermediate and final reports, DORA progressions, and HIPAA HHS supplemental detail, often running one to three months. The regulator inquiry phase covers supervisory letters, information requests, on-site visits, and resolution, often running six to eighteen months. The engagement stays open across all three phases on SecPortal so the chronology of decisions, notifications, amendments, and inquiries is queryable from one record. The post-event programme retrospective and the lessons-learned cycle close the engagement; the evidence pack remains on the workspace for the retention class the engagement records.

How it works in SecPortal

A streamlined workflow from start to finish.

Stand up the breach engagement at the moment a triggering event is suspected

When the security operations team confirms a triggering event candidate (suspected unauthorised access, data exposure, ransomware activity, integrity loss, availability event, third-party breach with downstream exposure), open a dedicated engagement on the workspace. Capture the event identifier, the discovery timestamp, the named incident commander, the named legal counsel, the named disclosure committee chair, the named privacy officer, and the in-scope assets, jurisdictions, and data categories at the moment they are known. The engagement is the single record every downstream decision reads against, so it has to exist before the first regulator clock starts ticking rather than be reconstructed later from a chat transcript.

Run the regulator-clock map and start every applicable countdown explicitly

Before any notification decision is made, the engagement records every regulator clock that may apply: GDPR Article 33 (supervisory authority within 72 hours of awareness, with reasoned delays documented), NIS2 Article 23 (early warning within 24 hours, incident notification within 72 hours, final report within one month), SEC Item 1.05 (Form 8-K within four business days of materiality determination), HIPAA Breach Notification Rule (HHS within 60 days, individuals without unreasonable delay), DORA Articles 19 and 20 (initial, intermediate, and final notifications on the prescribed schedule), state breach laws by jurisdiction, PCI DSS account data compromise notification to acquirers and brands, and contractual customer notification windows. Each clock records the start condition, the responsible owner, the deadline, and the reset triggers (a fresh discovery extending scope can restart certain clocks). Programmes that conflate clocks miss deadlines on the regulator nobody named explicitly.

Capture materiality and triggering-event evidence in a structured decision register

The disclosure committee runs the materiality determination on the engagement record rather than in a side document. Each determination logs the regulator regime, the criteria applied (financial impact, operational disruption, reputational impact, legal liability, customer harm, sector-specific factors), the data and findings the determination read against, the named decider, the timestamp, the dissenting views, and the reasoned conclusion. When the determination changes (a new finding extends the scope, a forensic update revises the timeline), a fresh determination is logged rather than the prior one being edited. The decision register is what the SEC, the FCA, the ICO, the OCR, the SAS, and the audit committee read when reconstructing what the company knew, when it was known, and what the reasoned response was.

Hold notification artefacts, draft disclosures, and counsel-reviewed evidence on the engagement

Every notification draft, regulator submission, customer communication, individual notice, and law-enforcement coordination letter is captured on the engagement with named author, reviewer, approver, and timestamp. Counsel-reviewed evidence (forensic logs, indicator analysis, scoping memos, attorney-client privileged work product flagged accordingly) lives in document management with retention class stamped at capture and the activity log capturing every state change. The custody chain matters because regulators and litigants will later read what was disclosed, when, and on what evidence base, and the answer has to be one query rather than a multi-week reconstruction.

Operate the parallel notification queues on a documented cadence with named owners

During an active breach the engagement runs parallel queues: regulator notifications (one queue per applicable jurisdiction with the clock, the owner, and the submission status), customer and individual notifications (often the largest queue by volume, with templating, segmentation, and bounce-tracking), law-enforcement coordination (FBI, NCA, Europol, regional CERT), insurer and broker notifications (cyber-policy carriers with notice-of-claim windows), board and audit-committee briefings (with materiality reads), and contractual partner notifications. A named queue owner reads each queue on a documented cadence (often hourly during the active phase, daily during stabilisation) and the engagement surfaces unresolved items before deadlines drift.

Track follow-up amendments, regulator inquiries, and post-notification obligations

Notification is rarely a one-shot event. SEC Item 1.05(c) requires amendment when material information becomes available; NIS2 requires the intermediate update at 72 hours and the final report at one month; GDPR contemplates further communication where information was incomplete; HIPAA HHS reporting carries supplemental detail through resolution; DORA mandates structured progressions. Each follow-up is a distinct decision on the engagement (new artefact, fresh decider, revised conclusion) so the chronology of notifications and their amendments is reconstructable as a single chain of decisions rather than a string of forwarded emails. Regulator inquiries that follow notification (information requests, supervisory letters, on-site visits) attach to the same engagement so the response builds on what was already disclosed.

Close the engagement with a regulator-ready evidence pack and a programme retrospective

When the active and amendment phases close, the engagement holds the entire notification record: the regulator-clock map with start and stop times, the materiality decision register with each determination chronology, the notification artefacts with custody chain, the queue execution log with named owners, the regulator inquiry responses, the law-enforcement coordination letters, and the activity log capturing every state change. AI-generated reports compose the disclosure narrative for the audit committee, the board read-out, the cyber insurer post-claim review, and the next external assurance cycle (ISO 27001 surveillance, SOC 2 examination, sector-specific audit). The programme retrospective lands on the same record so the next event reads against the lessons of the prior one.

Features that power this workflow

Orchestrate every security engagement from start to finish

Vulnerability management software that tracks every finding

Every action recorded across the workspace

Document management for every security engagement

AI-powered reports in seconds, not days

Collaborate across your entire team

Compliance tracking without a full GRC platform

Multi-factor authentication on every workspace

Notifications and alerts for the people who carry the work

Run breach notification and regulator readiness on one engagement record

Track every regulator clock, capture materiality determinations, hold notification artefacts with custody chain, and operate parallel notification queues without losing the chronology to email reconstruction. Start free.