D4 · Incident response
This plan defines how a security incident at Bolívar Connect is detected, contained, analyzed, fixed and communicated, and who does what.
1. What an incident is
Section titled “1. What an incident is”Any event that compromises or may compromise the confidentiality, integrity or availability of the platform or its data. For example:
- use of an API key by someone who should not have it, or an exposed credential;
- a tenant accessing another tenant’s data;
- duplicated, altered or unauthorized payment instructions;
- exposure of personal data;
- an outage of the service or of a regulated financial institution;
- anomalous activity in the infrastructure.
2. Severity
Section titled “2. Severity”| Level | Criterion | Initial response |
|---|---|---|
| SEV1 — Critical | Personal data exposed, unauthorized instructions, cross-tenant access or service down | Immediate, at any hour |
| SEV2 — High | Compromised credential without confirmed use, severe degradation or a third-party failure | Within 4 hours |
| SEV3 — Medium or low | Suspicious event without confirmed impact | On the next business day |
3. Roles
Section titled “3. Roles”| Role | Who | Function |
|---|---|---|
| Incident coordinator | Security Officer | Declares the incident, sets the severity, decides and coordinates |
| Technical team | On-call technical personnel | Contains, analyzes and fixes |
| Communications | Management | Notifies clients, third parties and authorities when appropriate |
Anyone on the team who detects a possible incident reports it immediately to the Coordinator.
4. Phases
Section titled “4. Phases”4.1 Detection and recording
Section titled “4.1 Detection and recording”Sources: anomalous authentication and rate-limiting rejections, third-party circuit breaker errors, reconciliation differences, notices from clients or third parties, and AWS alerts. An incident record is opened with the time of detection, the source and the initial severity.
4.2 Containment
Section titled “4.2 Containment”| Situation | Action |
|---|---|
| Compromised API key | Immediate revocation and issuance of a new one to the client |
| Exposed webhook secret | Secret rotation |
| Exposed third-party or infrastructure credential | Rotation in AWS Secrets Manager and service restart |
| Malicious traffic | IP restriction in the security group |
| Suspicious beneficiary | Beneficiary blocked |
| Failing third party | Circuit breaker, which takes it out of service |
| Server compromise | Instance isolated and recreated from infrastructure as code |
Evidence is preserved before any destructive change: logs, snapshots and the audit log.
4.3 Analysis
Section titled “4.3 Analysis”What happened is reconstructed using each request’s request_id, the audit
log, the status history of each payment instruction and the AWS logs. The
root cause, the scope (affected tenants, instructions and data) and the time
window are determined.
4.4 Fix and recovery
Section titled “4.4 Fix and recovery”The root cause is fixed with a regression test and the service is validated. If payment instructions were affected, they are reconciled against the regulated financial institution’s records before the incident is closed.
4.5 Communication
Section titled “4.5 Communication”| To whom | When | What |
|---|---|---|
| Affected clients | Within 24 hours of confirming a SEV1 or SEV2 that affects them | Scope, impact, measures taken and next update |
| Regulated financial institution | When the incident affects instructions sent to it | Affected instructions and required action |
| Data protection authority | Within 72 hours when there is a personal data breach subject to the GDPR or applicable regulation | What the regulation requires |
4.6 Closure and lessons learned
Section titled “4.6 Closure and lessons learned”Within 10 business days after closing a SEV1 or SEV2, a report is written with the timeline, root cause, impact, corrective actions and their owners. The actions are followed up until closed.
5. Plan testing
Section titled “5. Plan testing”The plan is tested at least once a year with a tabletop exercise on a realistic scenario, for example a leaked API key or a third-party outage. The result and improvements are recorded.
6. Contacts
Section titled “6. Contacts”The escalation contact list (team, Management, third parties and clients) is kept up to date outside this document and reviewed at every plan test.