Security Incident Response Policy

1. What counts as an incident

A security incident is any event that compromises, or is reasonably suspected to compromise, the confidentiality, integrity, or availability of personal data we process. This includes unauthorized access to client data, exposure of a credential or access token, unintended disclosure of one client's data to another, loss of data without a recoverable backup, and any compromise of a system holding client data.

A failed access attempt that our controls correctly refused is not an incident. A pattern of them is, and is treated as one.

2. Roles

myBloom is a small team, so the responsible person is named rather than a committee. The founder is the incident owner and the single point of contact for every incident, reachable at legal@mybloomhq.com. The incident owner may delegate technical containment but remains accountable for the client notification and the written record.

3. How incidents are detected

Privileged access to a client's connected accounts writes an entry to an append-only audit log, so unexpected access is visible after the fact. Platform providers notify us of credential compromise and revoked grants, and our connector health checks surface a credential that has stopped working. Clients and members of the public can report a suspected incident to legal@mybloomhq.com, and reports are acknowledged within one business day.

4. Response steps

1. Contain. Revoke or rotate the affected credential, and suspend the affected access path. Containment takes priority over diagnosis.
2. Assess. Establish what data was reachable, whose it was, and over what period, from the audit log and provider logs.
3. Notify. Inform every affected client without undue delay, and in any event within 72 hours of becoming aware, with what we know at the time rather than waiting for a complete picture.
4. Remediate. Fix the underlying cause, not the symptom, and verify the fix.
5. Record. Write up what happened, what was reachable, what was changed, and what prevents a recurrence.

5. Notification

A client is told what data was involved, when it happened, what we have done, and what if anything they need to do. Where a client is the controller and a regulator or their own customers must be told, we provide the information they need to meet that obligation and we do not make that notification on their behalf unless asked in writing.

Where an incident involves data from a connected platform, we notify that platform through the channel it requires and within the window it specifies.

6. Preventive controls this policy relies on

Secrets and access tokens are encrypted at rest with AES-256-GCM and are never written to logs or to a URL. Client data is isolated per tenant at the database, so a query cannot read across clients. Access to production credentials is limited to staff who need it. Every privileged use of a client's connected account is logged with the actor, the provider, and the action.

7. Review

This policy is reviewed at least annually, and after any incident. The reviewed date at the top of this document is the record of that.