Skip to main content

Incident Response Plan

Scope

This process covers suspected compromise, unauthorised access, personal-data breach, malware, credential exposure, provider incident, destructive change, denial of service, integrity failure, and material loss of availability affecting FinTrack.

Lifecycle

Use the controls to enlarge the diagram. Pan horizontally and vertically when zoomed.

Severity and response

SeverityExample impactResponse expectation
CriticalActive compromise, broad sensitive-data exposure, destructive attack, or prolonged critical outageImmediate mobilisation, management escalation, provider coordination, evidence preservation, and legal/privacy assessment
HighConfirmed unauthorised access, material tenant risk, or critical control failureUrgent containment and accountable owner; frequent status updates
MediumLimited incident with controlled impact or credible attempted compromiseTimely investigation, remediation, and monitored closure
LowPolicy event or suspicious activity with minimal impactRecord, triage, correct, and trend

Required record

The incident record includes detection time, reporter, affected services and data classes, severity, timeline, indicators, containment, decisions, evidence locations, communications, provider tickets, legal/privacy assessment, recovery validation, root cause, corrective actions, and closure approval. Secrets and personal data are not copied into broadly accessible incident summaries.

Communications

Only authorised personnel communicate externally. Notification timing and content follow contract and applicable law. Customers receive accurate known facts, impact, mitigations, and required actions; uncertain information is identified as such. Provider status information is verified before use.

Recovery and learning

Recovery requires authentication, authorization, tenant isolation, critical workflows, data integrity, monitoring, and external reconciliation checks. A post-incident review assigns actions, owners, due dates, and verification. Evidence is retained according to legal and security requirements.

Response roles and decision authority

RoleAuthority and responsibility
Incident commanderOwn severity, objectives, coordination cadence, containment decisions, and closure recommendation
Technical leadValidate indicators, preserve technical evidence, execute containment and eradication, and coordinate recovery validation
Application and data ownerDetermine business-object impact, affected tenants and workflows, integrity requirements, and reconciliation scope
Privacy and legal leadAssess personal-data and contractual notification obligations, preserve privilege, and approve external statements
Communications leadMaintain one approved customer and stakeholder narrative with versioned facts and action requests
Provider coordinatorOpen and track provider cases, preserve provider evidence, and reconcile provider status with observed application impact
ScribeMaintain the authoritative timeline, decisions, owners, evidence references, and action register

First-response protocol

  1. Record the report time, reporter, observed behavior, affected service, and available correlation evidence.
  2. Assign an initial severity and incident commander; open the restricted incident record.
  3. Preserve volatile evidence before destructive containment where preservation does not prolong harm.
  4. Revoke or rotate exposed credentials, isolate affected workflows, and block malicious access according to the confirmed scope.
  5. Identify affected tenants, personal-data classes, records, transactions, providers, and time window.
  6. Establish an update cadence and separate confirmed facts, working hypotheses, and rejected hypotheses.
  7. Eradicate the cause, deploy the controlled correction, and validate security plus business integrity.
  8. Reconcile external transactions and delayed provider events before declaring recovery.
  9. Obtain incident-command, technical, business, and privacy closure decisions.

Readiness limitation

This plan establishes the process but does not prove an active on-call roster, contact tree, tabletop exercise, notification template approval, forensic retainer, or measured response times. Those require internal operational evidence.