Security Disclosure Policy

DeterminedVAT, operated by DeterminedAI, LLC (a Delaware limited liability company), processes tax data on behalf of businesses. Reporting a security issue privately, before disclosing it publicly, helps us protect those customers.

How to report a vulnerability

Email security@determinedai.co with:

• A clear description of the issue.
• Steps to reproduce (URL, request, payload).
• The impact you believe an attacker could achieve.
• Any proof-of-concept material you have.

You should receive an acknowledgement within 2 business days.

If you do not receive a response, escalate by emailing jbburns@determinedai.co.

What we ask of reporters

• Give us a reasonable window — at least 30 days — to investigate and ship a fix before public disclosure.
• Do not run automated scanners that generate disruptive traffic against production. Limit testing to your own account / data.
• Do not access, modify, or destroy data that does not belong to you.
• Do not use the issue to extract customer data, file fraudulent tax returns, or otherwise harm DeterminedVAT customers or third parties.

Researchers acting in good faith and within the bounds above will not be pursued legally, and we will publicly credit you (with permission) once the issue is remediated.

What's in scope

• https://determinedai.co and https://www.determinedai.co
• The DeterminedVAT REST API (any /v1/* endpoint)
• The HMRC MTD submission flow (/v1/returns/mtd/*)
• The OSS / VAT calculation engine

What's out of scope

• Findings from automated tools without manual validation.
• Denial-of-service or volumetric attacks.
• Social engineering of DeterminedVAT staff or customers.
• Issues in third-party services we depend on (Vercel, Supabase, Stripe, HMRC) — please report those directly to the relevant vendor.
• Missing best-practice headers (HSTS, CSP) on pages that do not handle user data, unless you can demonstrate concrete impact.

Reporting an HMRC-related security incident

If a vulnerability has, or could have, affected the integrity of any VAT submission to HMRC, we will:

1. Notify HMRC by raising a ticket on the Developer Hub within 72 hours of becoming aware of the issue.
2. Notify the UK Information Commissioner's Office (ICO) within 72 hours if personal data was, or may have been, exposed.
3. Notify affected customers without undue delay, with a clear description of what happened and what we recommend they do.

Security incident response process

DeterminedVAT follows the timeline below for any confirmed or strongly-suspected security incident affecting customer or personal data, including incidents touching the HMRC MTD submission path. This is the process we attest to under HMRC's Developer Hub production-credentials checklist.

Breach contact for HMRC and ICO

• Name: J.B. Burns (Founder / Security Lead)
• Email: security@determinedai.co
• Backup: jbburns@determinedai.co
• Telephone: provided directly to HMRC SDST and ICO at notification time (kept off-website to limit phishing surface).

Phase 0 — Detection (T+0)

• Source: monitoring on Vercel logs, Supabase audit logs, Stripe webhook anomalies, customer report, or external researcher email to security@determinedai.co.
• On-call engineer triages within 1 hour of alert / report.
• If confirmed or plausibly confirmed, declare incident and start the timeline. The declared timestamp (T+0) is the moment of confirmation, not the moment of original compromise.

Phase 1 — Containment (T+0 to T+4 hours)

• Rotate any credentials that may have been exposed: Supabase service key, Stripe restricted keys, HMRC production OAuth client secret, any encryption keys (core/crypto.py Fernet keyset).
• Revoke active OAuth sessions for impacted users via Supabase admin API. For HMRC tokens, instruct affected customers to disconnect and re-authorise.
• Block egress on suspicious IPs at the Vercel firewall layer.
• Snapshot affected database state for forensic analysis before any remediation that mutates data.

Phase 2 — Scope assessment (T+4 to T+24 hours)

• Determine which customer accounts, data fields, and time periods are affected.
• Determine whether any HMRC submission was made under compromised credentials. If yes, identify the form bundle numbers and customers involved — they must be notified individually.
• Write a factual incident summary (what happened, when, scope, what is known vs. still under investigation). This becomes the basis for the regulator notifications.

Phase 3 — Regulator notification (T+24 to T+72 hours)

• HMRC — open a Developer Hub support ticket at https://developer.service.hmrc.gov.uk/developer/support with the subject [SECURITY BREACH] DeterminedVAT — <incident id>. Include: the incident summary, the breach contact's name + telephone number, affected VRNs (if any), and any form bundle numbers known to be involved.
• ICO — submit the personal-data breach notification at https://ico.org.uk/for-organisations/report-a-breach/ within 72 hours of awareness, following the Direct Marketing / GDPR notification format the ICO publishes.
• Both notifications go out even if the assessment is incomplete — provide what is known and update as further facts emerge. Late notifications are not acceptable to either regulator.

Phase 4 — Customer notification (T+72 hours onward)

• Email each affected customer directly using the address on their account, not a public blog post. Customers learn from us first.
• Email content covers: what happened, what data was exposed, what we have done, what they should do (e.g. rotate their HMRC OAuth authorisation), and where to ask follow-up questions.
• For incidents affecting more than one customer, publish a public post-mortem within 14 days of regulator notification at https://determinedai.co/security/incidents/<id>.

Phase 5 — Root cause and remediation

• Identify the root cause (configuration, code defect, third-party compromise, social engineering).
• Land remediation in code with tests that would have caught the defect. Tag the commit with the incident id.
• Update this runbook with any process gap surfaced by the incident.

Drills

• We run a tabletop exercise of this process at least annually, rotating the simulated incident type (credential leak, data exfiltration, HMRC-flow tampering). Notes from the most recent drill are kept in docs/security/drills/.

Contact

• Security reports: security@determinedai.co
• General contact: jbburns@determinedai.co
• Legal entity: DeterminedAI, LLC (Delaware, United States)
• Registered office: c/o Harvard Business Services, Inc., 16192 Coastal Highway, Lewes, DE 19958, United States