Breach reporting workflow

This page sets out the breach reporting workflow: the AR’s submission, the SUP 15 timing semantics, and the principal firm’s triage, materiality assessment, and notification path. The workflow runs from the AR’s first awareness of the breach through to closure and audit-chain finalisation.

The AR submission surface is /ar/breaches/new. The principal-side triage surface is /principal/breaches.

What counts as a breach

A breach is any departure from the FCA’s rules, the principal firm’s policies, or the regulatory expectations that govern the AR’s activity. The taxonomy on the form (category):

Category	Examples
conduct	Misleading advice, pressure-selling, unsuitable product recommendation
financial-crime	AML failure, fraud, sanctions breach
data-protection	UK GDPR breach, customer-data loss, mis-addressed correspondence
complaints-handling	DISP 1 timing breach, complaint not logged, FOS escalation failure
advice-suitability	MCOB / ICOBS / CONC suitability assessment failure
disclosure	Pre-contract disclosure failure, Consumer Duty disclosure failure
training-competence	Training gap, role-relevant qualification lapse
other	Anything not covered above; the principal firm reviews these for taxonomy expansion

When in doubt, the AR files the report. The principal firm’s compliance team makes the materiality assessment and decides whether the breach is notifiable to the FCA under SUP 15.

Submission schema

BreachReport (from lib/types.ts):

export interface BreachReport {
  id: Ulid; tenantId: Ulid; arId: Ulid;
  title: string; description: string;
  category: BreachCategory;
  severity: "minor" | "moderate" | "material" | "significant";
  customerImpact: "none" | "potential" | "actual-low" | "actual-high";
  awareAt: IsoTimestamp;                // Drives the SUP 15 clock
  reportedAt: IsoTimestamp;
  notifiedFcaAt: IsoTimestamp | null;
  notifyByAt: IsoTimestamp | null;      // Computed deadline
  rootCauseTaxonomy: string[];
  resolutionStatus: "open" | "in-remediation" | "resolved" | "closed";
  filedBy: Ulid;
  createdAt: IsoTimestamp; updatedAt: IsoTimestamp;
}

The AR fills title, description, category, severity, customerImpact, awareAt, and rootCauseTaxonomy. The server fills reportedAt, notifyByAt (the computed SUP 15 deadline), filedBy, and the timestamps.

Severity self-assessment

The AR sets the initial severity, with definitions surfaced inline at the form:

• Minor. Procedural failure with no customer impact and no risk of regulatory criticism.
• Moderate. Procedural failure with potential customer impact addressable through standard remediation.
• Material. Failure with actual customer impact or with conduct implications that warrant principal-side investigation.
• Significant. Failure that is reportable to the FCA under SUP 15.3.11R, or that has caused actual high customer detriment.

The AR’s self-assessment is a starting point. The principal firm’s compliance team can revise the severity at triage, with the revision recorded as an audit event. The AR sees the revised severity and the principal-side actor.

Customer impact

Value	Definition
none	No customer affected; the breach is internal.
potential	Customers could in principle have been affected but no actual harm occurred.
actual-low	Customers were affected but the harm is limited and easily remediated (e.g. a small fee refund).
actual-high	Customers were materially harmed (e.g. unsuitable advice, customer-data exposure to unauthorised recipient, financial loss above £500).

actual-high customer impact combined with material or significant severity is the strongest signal for a SUP 15 notification. The principal firm’s compliance team reviews these as P1.

The SUP 15 clock

The clock starts at awareAt. The AR’s awareAt is the moment they (or their colleague at the AR) became aware of the breach; not the moment they filed the report. A breach the AR became aware of three days ago and filed today carries awareAt = now - 3d and reportedAt = now.

The SUP 15 timing rules:

• SUP 15.3.11R (notifiable breach). A firm must notify the FCA immediately of any matter that could have a significant adverse impact on the firm’s reputation, customers, or the wider market. “Immediately” is interpreted in line with FCA guidance as no later than the next working day after the firm has had a reasonable opportunity to assess the matter.
• SUP 15.3.20R (data security and operational incidents). Firms must notify the FCA of significant operational and security incidents within tighter windows under the FCA’s own guidance and the relevant operational-resilience rules.
• SUP 15.7 (form requirements). Notifications use the prescribed forms (REP008 in many cases) and must include the specified content.

The workspace computes notifyByAt based on the severity and customer impact:

Severity x Impact	notifyByAt window from awareAt
significant x actual-high	1 working day
material or significant x actual-low or potential	5 working days
material x none	30 working days (operational review)
moderate and below	No FCA notification deadline; principal-side review only

These windows are guidance, not bright lines. The principal firm’s compliance team makes the materiality and timing assessment per breach. The workspace surfaces the computed deadline; the actual decision is human.

State machine

stateDiagram-v2
  [*] --> Reported
  Reported --> Triaged: principal opens
  Triaged --> Investigating: assigned
  Investigating --> AssessingMateriality: facts captured
  AssessingMateriality --> NotifiableToFca: material or significant
  AssessingMateriality --> InRemediation: not notifiable
  NotifiableToFca --> NotifiedFca: SUP 15 notification recorded
  NotifiedFca --> InRemediation
  InRemediation --> Resolved
  Resolved --> Closed
  Closed --> [*]

The principal-side compliance team drives the state machine after the AR’s submission. Each transition is an audit event with the actor and a note.

AR submission flow

The AR-user opens /ar/breaches/new. The form:

1. Title and description. Free-text. Description requires a minimum of 20 characters; the UI guides the AR to capture the chronology, the people involved (by role, not by customer name), the systems involved, and the immediate steps already taken.
2. Category, severity, customer impact. Dropdowns with inline definitions.
3. Aware at. Date-time picker. The AR enters when they first became aware. This is the input the principal-side compliance team will scrutinise; if the AR’s awareAt is materially earlier than reportedAt, the team asks why.
4. Root cause taxonomy. Up to 8 short tags from the firm’s configured taxonomy.
5. Submit. The submission lands in the principal-side breach triage queue and writes breach.reported to the audit chain.

The AR sees a confirmation screen with the breach ID, the principal-side compliance contact, and the next steps. The AR can return to the breach via /ar/breaches/[id] to see the principal-side updates.

The form does not let the AR backdate reportedAt. The reported timestamp is server-assigned at the moment of submission. Backdating awareAt is allowed (the AR may have learned of the breach earlier) but is reviewed by the principal-side team.

Principal triage flow

The principal-compliance-officer sees the breach in /principal/breaches. The triage queue is sorted by notifyByAt ascending, so the most time-sensitive breaches surface first.

Triage steps:

1. Open and read. The officer opens the breach detail page (/principal/breaches/[id]). The page shows the AR’s submission, the AR’s history (prior breaches, recent file reviews, MI return trends), and the SUP 15 timing widget.
2. Confirm or revise severity and customer impact. The officer’s revision (if any) writes an audit event with the prior and new values.
3. Materiality assessment. The officer captures the assessment in the breach detail page, with a structured prompt covering reputation impact, customer impact, market impact, and any tie to the firm’s recent issues.
4. Decide notifiability. Either notify the FCA (POST /api/breaches/:id/notify-fca, step-up authentication required) or progress to in-remediation without notification.
5. Remediation plan. The officer captures the remediation steps, owners, and target dates.
6. Resolve and close. The breach progresses through resolved to closed as the remediation completes. Closure is a write that records the final state and the actor.

A breach the firm chooses not to notify when the workspace’s computed notifyByAt would suggest it should, the firm captures the reasoning in the breach detail page. The audit chain preserves the reasoning for any later regulator review.

FCA notification

POST /api/breaches/:id/notify-fca is the terminal action that records the notification. The handler:

1. Requires step-up authentication (re-enter password and TOTP within the last 5 minutes).
2. Sets notifiedFcaAt = now().
3. Writes a breach.notified-fca audit event with the principal-admin actor, the step-up event id, and the form-of-notification field (REP008, email, telephone).
4. Generates a CSV / PDF bundle of the notification artefact for the firm’s records (production only; the demo records the timestamp without artefact generation).

The actual transmission to the FCA happens out of band via the FCA’s standard channels. The workspace records the timestamp and the actor. The firm’s compliance team is responsible for delivering the notification to the FCA via the correct channel and form.

Visibility to the AR

The AR who filed the breach sees:

• The breach in their own surface at /ar/breaches/[id].
• Every state transition with the principal-side actor’s name and role.
• The principal firm’s revisions to severity, customer impact, and root-cause taxonomy.
• The FCA notification timestamp (where applicable) without the form details.
• The remediation plan as captured by the principal-side team.

The AR cannot edit the breach after submission. The AR can append clarification notes, which are captured as breach.note-appended audit events.

The AR does not see breaches filed against them by the principal-side team without their involvement; the AR sees those (in their own /ar/audit surface) but does not see the principal-side internal commentary on them.

Closure

Closure (resolutionStatus = "closed") is the terminal state. After closure:

• The breach record is immutable on the AR side and on the principal-side write paths (the audit chain still receives breach.note-appended events for further commentary, but the substantive fields are locked).
• The breach is included in the AR’s annual review packet aggregation.
• The breach is included in the firm’s quarterly board pack.
• Retention runs from closedAt + 7 years per retention.

Operational notes

A breach that approaches its computed notifyByAt without progress writes a breach.deadline-approaching audit event 24 hours and 4 hours before the deadline; the principal-side compliance team gets a workspace banner. Missed deadlines (now > notifyByAt and notifiedFcaAt is null for a breach in NotifiableToFca) write breach.deadline-missed and surface as a P1 banner; the firm’s SMF16 is the named escalation in firm settings.

A breach that the AR reports for an AR they are no longer associated with (the AR-user has been off-boarded since awareAt) is captured under the off-boarded user’s tombstoned attribution. The principal-side compliance team sees the chronology with the opaque token in place.