1. Purpose and scope
The purpose of this policy is to ensure that security incidents are detected quickly, contained, investigated, and remediated in a consistent way, and that affected merchants are notified promptly and accurately. This policy applies to all systems that store or process merchant or customer personal data, including our Cloudflare Workers infrastructure, PostgreSQL database (Neon), object and key-value storage (R2, KV), background job execution (Trigger.dev), and the sub-processors listed in the DPA.2. What counts as a security incident
A security incident is any event that compromises, or that we reasonably believe may compromise, the confidentiality, integrity, or availability of data we process. Examples include:- Unauthorised access to, or disclosure of, merchant or customer personal data.
- Compromise of application credentials, access tokens, encryption keys, or infrastructure accounts.
- Exploitation of a vulnerability in the application or a sub-processor.
- Loss, corruption, or unavailability of merchant data beyond expected service limits.
- Malware, ransomware, or other malicious activity affecting our systems.
3. Severity classification
Incidents are classified on first assessment and re-assessed as facts change:4. Roles and responsibilities
Given the size of our team, one person holds primary responsibility for security incident response as the Incident Lead. The Incident Lead:- Owns the response from detection through to post-incident review.
- Decides severity, containment actions, and whether a personal data breach has occurred.
- Coordinates with sub-processors’ security and support teams where an incident originates with or involves them.
- Owns merchant and regulator communications, or delegates drafting while retaining approval.
5. Response process
We follow a consistent lifecycle for every incident. Steps run concurrently where appropriate; containment is never delayed for the sake of process.- Detect and report. Incidents surface through automated monitoring and alerting (Sentry error tracking, Axiom operational analytics and event logging), sub-processor notifications, or reports from merchants and security researchers sent to support@stockful.app. Anyone who suspects an incident must report it to the Incident Lead without delay.
- Triage and classify. The Incident Lead confirms the incident is genuine, assigns an initial severity (Section 3), and begins an incident record capturing timeline, actions, and evidence.
- Contain. Limit the blast radius — for example rotate or revoke compromised credentials and access tokens, disable affected functionality, block malicious traffic, or isolate affected systems. Preserve evidence needed for investigation.
- Eradicate. Remove the root cause — patch the vulnerability, revoke unauthorised access, remove malicious artefacts, and correct the misconfiguration.
- Recover. Restore affected systems and data to normal operation from known-good state, verify integrity, and confirm the issue is resolved before standing down. Where data restoration is required, we restore from the encrypted, point-in-time backups maintained by our database provider.
- Notify. Where the incident is a personal data breach, follow Section 6.
- Review. Conduct a post-incident review (Section 7).
6. Notification
Where an incident is a personal data breach, we notify each affected merchant without undue delay, and in any event within 72 hours of becoming aware of the breach, consistent with Section 10 of the Data Processing Agreement. The notification includes, to the extent known at the time:- The nature of the breach.
- The categories and approximate number of data subjects and records concerned.
- The likely consequences of the breach.
- The measures taken or proposed to address it and to mitigate its effects.
Incidents involving connected marketplace accounts
Where an incident affects information obtained from a connected marketplace account, we additionally notify that marketplace on the timetable its own terms require, and the shorter of that timetable and the one above applies. For information obtained through the Amazon Selling Partner API, we report security incidents to security@amazon.com within 24 hours of detection, and we notify affected merchants of the same incident within 24 hours rather than the 72 hours that applies elsewhere. This is a commitment under the Amazon Services API Data Protection Policy and it is not conditional on the incident amounting to a personal data breach: any suspected compromise, unauthorised access, or unauthorised disclosure of Amazon Information is reported.7. Post-incident review
After every SEV1 and SEV2 incident, and at the Incident Lead’s discretion for SEV3, we conduct a post-incident review that documents the timeline, root cause, impact, and the effectiveness of the response, and that agrees concrete remediation actions to reduce the likelihood and impact of recurrence. Remediation actions are tracked to completion.8. Testing and maintenance
This policy is reviewed at least every six months and after any SEV1 incident, and updated to reflect changes to our systems, sub-processors, and the threat landscape. The six-month cadence is the shortest required by any platform whose data we process, so one review satisfies all of them. Our detection and alerting configuration is reviewed as part of ongoing operations.9. Reporting a security concern
If you believe you have found a security vulnerability or have witnessed a security incident affecting Stockful, please contact us as soon as possible:- Email: support@stockful.app