Incident Response Policy

Last updated: August 8, 2026

This policy defines how Assenture detects, triages, contains, resolves and communicates security incidents affecting our production systems or customer data, including any consumer financial data received through our bank aggregation partner. It applies to all personnel and contractors and is read together with our Security Policy, Logging and Monitoring Policy and Data Processing Addendum.

1. Scope and definitions

• Event. Any observable occurrence in a system or network.
• Security incident. An event that compromises, or credibly threatens, the confidentiality, integrity or availability of production systems or data.
• Personal data breach. An incident leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data.

2. Roles

• Incident Commander. The on-call engineering lead. Owns the response, declares severity, coordinates workstreams and authorises containment actions.
• Technical responders. Engineers performing investigation, containment and recovery.
• Communications lead. Owns customer, partner and regulator notifications and the status page.
• Privacy lead. Determines whether an incident is a personal data breach and drives regulatory assessment.
• Roles may be held concurrently by the same individual in a small team, but the Incident Commander is always explicitly named for each incident.

3. Detection and reporting

• Automated detection through centralised logging, error tracking, anomaly alerts on authentication failures, privilege escalation, unusual export volume and data-exfiltration signals, as described in our Logging and Monitoring Policy.
• Any employee, contractor, customer or external researcher can report a suspected incident to business@assenture.app. Reports are monitored continuously and acknowledged within 24 hours.
• Good-faith external security research is welcomed; we do not pursue legal action against researchers who follow responsible disclosure and do not access or exfiltrate other users' data.
• Reporting a suspected incident is mandatory for personnel and must never be delayed for fear of blame. Response is blameless.

4. Severity classification and response targets

5. Response lifecycle

1. Triage. Validate the report, assign severity, name the Incident Commander and open a timestamped incident record.
2. Contain. Limit blast radius: revoke sessions, tokens and keys, disable the affected code path or integration, isolate the affected component, block the offending source.
3. Investigate. Preserve logs and evidence in write-once storage before remediation alters state. Establish scope: which records, which tenants, which individuals, over what window.
4. Eradicate. Remove the root cause: patch the defect, rotate compromised credentials, remove unauthorised access or artefacts.
5. Recover. Restore service from known-good releases or verified backups, confirm data integrity, and monitor at heightened sensitivity for recurrence.
6. Close. Confirm containment and eradication, document the final scope and complete notifications.

6. Notification

• Customers. Affected customers are notified without undue delay and, for confirmed personal data breaches, within 72 hours of Assenture becoming aware. Notice states what happened, the data categories affected, what we have done, and what the customer should do.
• Controllers. Where Assenture acts as processor, we notify the customer as controller without undue delay so they can meet their own regulatory deadlines, and we provide reasonable assistance with their assessment.
• Regulators. Where Assenture is controller, supervisory authorities are notified within the statutory period applicable to the jurisdiction (72 hours under GDPR, and as required under Singapore's PDPA).
• Partners. Incidents that involve or may involve data received through our bank aggregation partner are reported to that partner promptly and within any contractually agreed window, including preliminary notice before the investigation concludes.
• Status communication. Availability incidents are communicated through our status channel with periodic updates until resolution.

7. Evidence, forensics and retention

• Audit logs, access logs and application logs relevant to an incident are preserved beyond normal retention for the duration of the investigation and any subsequent legal or regulatory process.
• Evidence handling maintains chain of custody: who collected what, when, and from where.
• External forensic assistance is engaged for SEV1 incidents where internal capability is insufficient.

8. Post-incident review

• Every SEV1 and SEV2 incident receives a written blameless post-incident review within 5 business days of closure, covering timeline, root cause, detection gap, containment effectiveness and customer impact.
• Each review produces tracked corrective actions with named owners and due dates. Critical corrective actions are targeted for completion within 30 days.
• Review outcomes feed back into detection rules, secure coding standards and the change management process.

9. Preparedness and testing

• On-call coverage is maintained with a documented escalation path and out-of-hours contacts.
• Response procedures are exercised at least annually through a tabletop or simulated incident, including a breach-notification decision path.
• Backup restoration is tested periodically so recovery objectives are evidence-based rather than assumed.
• All personnel receive security awareness training at onboarding covering incident recognition and reporting.

10. Ownership and review

This policy is owned by Assenture engineering leadership, and is reviewed and approved at least annually and after any SEV1 incident. Contact: business@assenture.app.