Incident Response Plan

1. Purpose

This plan sets out how CompleteFlow Ltd identifies, triages, contains, investigates, eradicates, recovers from, and learns from security and privacy incidents. It is designed to meet CompleteFlow's obligations under UK GDPR Articles 33 and 34, the commitments it makes to customers in its Data Processing Agreement, and the expectations of regulated-sector customers in law, finance, and insurance.

2. Scope

This plan applies to:

• Security incidents affecting CompleteFlow's own systems, accounts, or personnel
• Security incidents affecting the CompleteFlow platform as deployed into customer Azure subscriptions, to the extent CompleteFlow has visibility or control
• Personal data breaches for which CompleteFlow is controller or processor
• Supplier-side incidents that may propagate to CompleteFlow or its customers

It operates in conjunction with CF-POL-001 Information Security Policy, CF-POL-002 Data Protection Policy, CF-POL-007 Supplier Management Policy, and CF-PLAN-002 Business Continuity and Disaster Recovery Plan.

3. Definitions

• Event: an observable occurrence in a system or network.
• Security incident: an event that actually or potentially compromises the confidentiality, integrity, or availability of information or systems.
• Personal data breach: a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data, as defined in UK GDPR Article 4(12).
• Near miss: an event that did not result in an incident but could have if a control had not operated as intended.

4. Roles and responsibilities

For smaller incidents, multiple roles may be held by the same person. The Incident Commander explicitly names roles at the start of an incident and documents transitions in the incident log.

5. Severity classification

Severity is assigned on first triage by the Incident Commander and is reviewed as investigation progresses. Severity may be upgraded or downgraded based on evidence; all changes are logged.

Customer notification follows the UK GDPR Article 33(2) standard of "without undue delay after becoming aware" where CompleteFlow is processor. Specific response-time commitments, escalation contacts, and out-of-hours arrangements are set out in the customer's Data Processing Agreement and Master Services Agreement.

5.1 Support hours

Standard platform support is provided during UK business hours (09:00–17:30 Monday to Friday, excluding UK public holidays). Out-of-hours incidents are triaged at the start of the next business day, with immediate escalation where there is evidence of an ongoing attack, active data exposure, or sustained platform unavailability. Extended or 24×7 support can be agreed as part of a customer's SLA.

6. Lifecycle

6.1 Identification

Potential incidents may be identified through:

• Microsoft Defender for Cloud and Azure Sentinel alerts on customer subscriptions (where enabled)
• Custom KQL detections on the Azure audit log (for example, PIM activation outside business hours, unusual data egress, failed authentication bursts)
• Application audit log alerts (for example, unusual tool invocation rates, failed application-authorisation spikes)
• Customer reports via established contact channels
• Personnel reports via the internal incident reporting channel
• Supplier security advisories and breach notifications
• External notifications (security researchers, CERT-UK, law enforcement)

6.2 Reporting

• Personnel: report suspected incidents immediately via the dedicated internal channel. Reporting in good faith is encouraged; failing to report a known incident is a breach of CF-POL-004.
• Customers: may report suspected incidents to security@completeflow.ai or via their established escalation contact.
• Third parties: may report via security@completeflow.ai; a published vulnerability disclosure policy applies.

Reports are triaged by the Incident Commander (or deputy) during UK business hours. Out-of-hours reports are triaged at the start of the next business day, with immediate escalation where the reporter indicates ongoing attack, data exposure, or sustained platform unavailability. First acknowledgement is sent to the reporter within the applicable triage period.

6.3 Triage

On report, the Incident Commander:

1. Opens an incident record with a unique ID, reporter, summary, first-seen time, and initial severity
2. Assembles the relevant roles and a private communication channel
3. Begins the contemporaneous incident log
4. Performs initial scoping, which system, which customer(s) if any, which data categories, which controls are or may be in scope
5. Makes an initial severity determination
6. Decides whether to invoke BCDR procedures (CF-PLAN-002) in parallel

6.4 Containment

Containment actions are chosen to limit damage while preserving evidence where practicable. Typical actions include:

• Revoking sessions, tokens, or credentials
• Disabling or restricting an affected account
• Isolating an affected compute resource (network rule changes, stopping an AKS node pool, taking a deployment out of rotation)
• Pausing a workflow or agent run in the orchestrator
• Applying an emergency deny rule in the application authorisation policy bundle
• Rotating affected secrets in Azure Key Vault
• Engaging the customer for any action that requires access to their subscription owner accounts

6.5 Investigation

• Timeline reconstruction from Azure audit logs, application audit log, workflow run logs, and endpoint telemetry
• Scope determination, which users, workflows, customers, data categories, time windows
• Root-cause analysis, the immediate cause and the control failure(s) that permitted it
• Evidential handling, logs preserved under legal hold where potentially relevant to regulator notification or litigation
• Where required, digital forensics via an agreed external provider

6.6 Eradication

• Removing attacker presence (credentials, persistence mechanisms)
• Patching or reconfiguring affected components
• Re-deploying clean versions of compromised services
• Rotating secrets with a wider blast radius than the confirmed compromise

6.7 Recovery

• Restoring service to defined recovery points (see CF-PLAN-002)
• Verification that the incident has been fully eradicated before returning to normal operations
• Enhanced monitoring for a defined period post-recovery
• Customer acceptance where their environment has been affected

6.8 Post-incident review

Within 14 calendar days of closure of any Sev 1 or Sev 2 incident, a post-incident review is held. The review is blameless, focuses on contributory causes, and produces:

• A written report, including timeline, root cause, contributory factors, and impact
• A set of remediation actions with owners and due dates
• Updates to the risk register (CF-REG-001)
• Any updates to policies, procedures, or controls required to prevent recurrence

Summary findings from Sev 1 incidents are shared with affected customers.

7. Customer notification

Customer notification timelines are those committed in CompleteFlow's customer contracts and DPA, and summarised in section 5 above. The Customer Communications Lead owns the flow.

• Initial notification: without undue delay after confirmation, using the contact channel and response window specified in the customer's contract.
• Content: what happened, what is known, what is being investigated, the customer impact, any actions the customer should take, and the next update time.
• Updates: on material change, or at the cadence agreed in the initial notification, until closure.
• Closure: final report describing the incident, root cause, impact, and remediation.

Templates for each of these are maintained by the Customer Communications Lead.

8. Regulator notification

8.1 UK GDPR Article 33 (ICO)

Where CompleteFlow is controller and has become aware of a personal data breach, the Information Security Officer (supported by legal counsel) assesses whether it is notifiable to the ICO under Article 33. Notifiable breaches are reported without undue delay, and within 72 hours where feasible.

Where CompleteFlow is processor, it notifies the affected customer(s) without undue delay on becoming aware of a breach (Article 33(2)), providing sufficient information to enable the customer to meet its own Article 33 and 34 obligations.

8.2 UK GDPR Article 34 (data subjects)

Where a breach results in a high risk to the rights and freedoms of data subjects, affected data subjects are notified without undue delay, using the mechanisms specified in Article 34(2). For incidents where CompleteFlow is processor, this obligation generally rests with the customer as controller; CompleteFlow supports the customer with information and evidence as required.

8.3 Sectoral regulators

Where an incident may have reporting implications under a sectoral regime (FCA, SRA, Bar Standards Board, PRA), the Legal and Regulatory Lead identifies the relevant regime in consultation with the affected customer and external counsel. Sectoral reporting is typically a customer obligation, but CompleteFlow supports the customer with timely and accurate information.

8.4 Law enforcement

Where an incident involves a suspected criminal act (for example, unauthorised access under the Computer Misuse Act 1990), the Information Security Officer decides, in consultation with legal counsel and the affected customer(s), whether to report to the relevant police force, Action Fraud, or the National Crime Agency.

9. Communication

9.1 Internal

During an incident, a dedicated, access-controlled channel is used for all operational communications. The incident log is maintained in a protected location and referenced but not continuously updated in chat. All communications within the channel are treated as confidential and subject to legal hold where applicable.

9.2 External

External communications are coordinated by the Customer Communications Lead. Public statements (for example, on the CompleteFlow status page, via email to customers, or via social channels) are authorised by the Incident Commander and reviewed by the Legal and Regulatory Lead before release. Individuals other than the nominated spokesperson(s) do not communicate externally about the incident.

9.3 Templates

• Initial customer notification
• Update customer notification
• Final customer notification
• ICO notification (Article 33)
• Data subject notification (Article 34)
• Status page statement

Templates are reviewed annually and after each Sev 1 incident.

10. Evidence handling

• Logs and artefacts relevant to an incident are preserved under legal hold immediately on declaration
• Preservation extends to Azure Monitor logs, application audit logs, workflow run records, and any relevant code or configuration at the time of the incident
• Chain of custody is maintained where evidence may be required for regulator reporting or litigation
• Handling of personal data within evidence respects UK GDPR principles; exports are minimised and access is restricted to named individuals

11. Testing and exercising

• Tabletop exercise: at least annually, scenario-based, involving core incident response roles. Findings feed back into this plan and the risk register.
• Technical drills: periodic drills of specific capabilities (credential rotation, forced sign-out, emergency policy deny rule), scheduled by the Information Security Officer.
• Post-incident validation: lessons from real incidents are reflected in plan updates.

The outcomes of exercises are recorded. Gaps identified are tracked through to closure in the risk register.

12. Training and awareness

• All personnel receive incident reporting training during induction and at annual refreshers (per CF-POL-001 section 7.3)
• Named incident response roles undergo scenario-based training annually
• Role-specific reference cards are maintained for Incident Commander, Technical Lead, and Customer Communications Lead

13. Records

Incident records are retained for 7 years per CF-POL-006 section 5. They include:

• The incident log (contemporaneous timeline)
• Post-incident review report
• Notifications sent (customer, regulator, data subjects)
• Evidence preserved
• Remediation actions and their closure

14. Document control