Security Statement

Customer Compass is a proactive revenue-and-risk decision agent for service businesses on Xero. This Security Statement describes the technical and organisational measures we use to protect your data — the same document we ship with the Xero App Marketplace certification pack.

Customer Compass was the Winner of the Cash Flow Accelerator category at the Xero Rise of the Builder Hackathon 2026 (judged by Xero). The certification package below reflects the security posture that has been in place since the earliest hackathon prototypes: KMS-encrypted per-user token storage, deterministic maths with AI only writing the words, and OAuth 2.0 scoped to the minimum needed to run each scan.

If you have a security question that this document does not answer, email support@customercompass.ai for standard questions or the DPO at chris@digitaltactics.co.uk for a data-protection review.

Every connection to Customer Compass — from your browser, from Xero, from Stripe webhooks, and between our own AWS services — uses TLS 1.2 or better. TLS 1.0 and 1.1 are disabled.

ACM-managed certificates are auto-renewed for all seven customer-facing hostnames: customercompass.ai, www.customercompass.ai, app.customercompass.ai, login.customercompass.ai (reserved), customercompass.co.uk, www.customercompass.co.uk, plus the staging equivalents.

HSTS is enabled on every domain we serve, with a 12-month max-age and includeSubDomains. Cookies containing session tokens are set with Secure, HttpOnly, SameSite=Lax, scoped to .customercompass.ai.

All customer data is encrypted at rest using a single customer-managed AWS KMS key (CMK) per environment (dev, staging, prod). We do not share KMS keys between environments and we do not use the AWS-managed default keys for anything containing customer data.

• DynamoDB tables — SSE-KMS enabled with the app CMK. Includes user state, Xero token bundles, billing state, credit ledger, scan metadata, audit log and telemetry tables.
• S3 scan-blob bucket — SSE-KMS enabled with the same CMK; bucket key enabled to reduce per-object KMS calls without weakening the crypto.
• Backups — encrypted DynamoDB point-in-time backups inherit the same SSE-KMS setting.
• Logs — CloudWatch log groups containing anything more than framework noise use SSE-KMS with the app CMK.

Key rotation is enabled annually on the CMK. The key policy grants encrypt / GenerateDataKey to the application Lambda, encrypt+decrypt to the account-delete Lambda (which needs to prove ownership by decrypting before deleting), and no grants to the Stripe webhook Lambda (defence in depth — the webhook path never needs to touch customer secrets).

Xero access tokens and refresh tokens are the highest-value secret we store. We deliberately chose DynamoDB with KMS envelope encryption and per-user encryption context over the two obvious alternatives, and we want to be explicit about why.

• Why not S3? S3 is object storage. Per-object access control is more expensive to reason about than per-row row-level authorisation, and S3 versioning makes secure token rotation harder — old versions can be recovered from a compromised operator account. DynamoDB delete is authoritative; S3 delete-with-versioning is not, unless every write also purges old versions.
• Why not AWS Secrets Manager? Secrets Manager is priced per secret per month, so per-user tokens would balloon the bill at any real scale. It is also designed for machine-to-machine credentials with low rotation cadence, not for OAuth tokens that refresh on demand.
• Why DynamoDB + KMS CMK? Per-row access with row-level IAM, encrypted-at-rest by the CMK, and encrypted a second time inside the row payload by an envelope key bound to the user's Cognito sub. Even an operator with broad DynamoDB read access cannot decrypt a token for the wrong user — the KMS decrypt call fails because the encryption context does not match.

The encryption context used on every KMS Encrypt and Decrypt call is { cognitoSub, purpose: 'xero-token' }. If either field mismatches at decrypt time, KMS rejects the call and the API hard-fails with 500 token_context_mismatch. The failure is alarmed and never auto-heals — this is deliberate, so that a real cross-user access attempt cannot be masked as a retryable transient error.

User authentication uses Amazon Cognito. Password policy: minimum 8 characters with mixed case, digits and symbols. Every new sign-up and every subsequent sign-in is checked against the HaveIBeenPwned breach corpus via a Cognito Lambda trigger. Passwords found in the corpus are rejected with a generic "please choose a stronger password" message — we do not leak which corpus matched.

Email verification is enforced — a user cannot sign in until their verification link has been followed. The verification link is valid for 24 hours; expired links re-prompt for a fresh send. This is a plain reviewer-facing fact for the Xero certification pack.

Optional TOTP MFA is available from /uk/account/mfa. SMS MFA is deliberately not offered because of SIM-swap risk.

Google and Microsoft social sign-in are supported via OIDC. The IdP callback URLs are locale-agnostic (Amendment 13) — a single URL per purpose per environment — so we do not have to re-register callback URIs to open new locales.

Server-side, the application Lambda, the Stripe webhook Lambda, and the account-delete Lambda run under separate IAM roles with least-privilege permissions. The telemetry table uses append-only IAM — no role in the application can update or delete an existing telemetry row.

Customer data is hosted in the AWS London region (eu-west-2). Our full sub-processor list, with region and category of data, is in the Privacy Policy. Highlights:

• AWS — eu-west-2 — infrastructure hosting for all customer data.
• Anthropic — LLM used to draft the wording of insights and actions. Payload is insight metadata only; no full invoices, no personal names, no bank information.
• OpenAI — fallback LLM with the same restricted payload shape.
• Stripe Payments UK Ltd — payment processing. Receives email address, billing address and card data. Card data never touches our systems.
• Xero Ltd — the accounting platform you connect. Joint controller with Digital Tactics Ltd for your accounting data.
• Amazon SES — transactional email delivery.
• Microsoft 365 — inbound support email hosting for support@customercompass.ai.
• Google (Analytics 4) — anonymised event metadata only, opt-in, UK-region data setting, IP anonymisation on.

International transfers rely on the UK IDTA / Addendum. Transfer impact assessments are held internally and are available on request to chris@digitaltactics.co.uk.

We commit to an annual third-party penetration test of the production environment. The first cycle is scheduled inside the marketplace-launch programme; the executive summary of each report will be available to enterprise prospects and to Xero reviewers on request under NDA. Remediation of critical and high findings is tracked to closure and re-tested. Full commitment text: annual pen-test commitment.

Automated static analysis and dependency-vulnerability scanning run on every pull request. Base container images and Lambda runtimes are updated at least monthly. Critical CVEs affecting the production stack are triaged within one business day and patched inside seven days where a fix exists.

We do not run a public bug-bounty programme at launch. If you believe you have found a security issue, please email chris@digitaltactics.co.uk with the details. We aim to acknowledge within one business day and, where the finding is confirmed, we will credit you in the Security Statement changelog if you would like us to.

Our incident-response playbook covers detection, triage, containment, eradication, recovery and post-incident review. On-call rotation is documented internally at docs/security/incident-response.md. Alarms include:

• KMS token_context_mismatch — pages on-call immediately (potential cross-user access attempt).
• Stripe webhook signature failures above a per-hour threshold.
• Elevated 5xx error rates on the API Lambda.
• Unusual patterns in the audit log (for example, mass account-delete requests from a single IP).

If a personal-data breach affects your data and is likely to result in a risk to your rights and freedoms, we will notify the UK ICO within 72 hours of becoming aware, in line with UK GDPR Art. 33. We will notify you without undue delay where the breach is likely to result in a high risk to your rights and freedoms (Art. 34). Our ICO registration is Z2807798.

We keep an internal breach register regardless of severity, so that near-misses feed the next round of hardening.

The commitments below are the numbers we ship to the Xero App Marketplace certification pack. They form part of your contract with us alongside the T&Cs at /uk/terms. Enterprise agreements with tighter SLAs are available on request.

• Uptime SLA — 99.5% monthly average, measured over each calendar month and excluding scheduled maintenance windows we announce in advance and events outside our reasonable control (force majeure, sub-processor outages that we could not have mitigated). Historical uptime figures are available on request.
• Support SLA — initial response within 2 business days from support@customercompass.ai. UK business days, Monday to Friday excluding English bank holidays. Initial response means an acknowledgement from a named human, not an autoresponder. Ongoing response cadence during an open ticket is agreed between you and the responder.
• Annual penetration-test cadence. Third-party penetration testing of the production environment on an annual cycle, with the first cycle scheduled inside the marketplace-launch programme. Full commitment at docs/security/pen-test-commitment.md and summarised in §7 above.
• Breach-notification cadence. ICO notification within 72 hours of first detection where UK GDPR Art. 33 applies; affected users notified without undue delay under Art. 34 where high risk is likely. See §8 above.

If we breach the uptime SLA, our T&Cs describe the remedies available. If we breach the support SLA, please escalate to the DPO at chris@digitaltactics.co.uk.

Customer Compass runs on AWS managed services — Cognito, DynamoDB, S3, Lambda, SES, SQS, KMS — with per-service resilience baked in. DynamoDB uses on-demand capacity with point-in-time recovery enabled (35-day rolling window). S3 is versioned with SSE-KMS. The application Lambda runs in one AWS region (eu-west-2) with automatic multi-AZ within the region; we do not currently offer multi-region active-active.

The uptime target and the mechanics behind it are quoted in §9 above. If a region-level AWS event exceeds our reasonable-control envelope we invoke the incident-response playbook (§8) and communicate through the support inbox.

We run three completely separate environments — dev, staging, prod. Each has its own Cognito user pool, its own DynamoDB tables, its own S3 bucket, its own KMS CMK, its own SES sending identity, its own Stripe mode (test in staging, live in prod), and its own Xero app registration.

Data does not flow from prod to non-prod. No developer laptop holds customer data at rest. Local development runs against the deterministic fixture organisation (src/__fixtures__/consultancyOrg.ts) and the offline FakeProvider — the same design that lets the demo tab run without any credentials at all.

Digital Tactics Ltd is a small operation. Access to production is restricted to the smallest engineering headcount that can safely operate the service, currently a single named individual (Christopher Dean). Production access uses AWS IAM Identity Center with hardware-key MFA. All production changes are made via infrastructure-as-code (Amplify Gen 2 + CDK escape hatches) and reviewed in pull request before deployment.

Every person with production access completes annual data-protection refresher training and reads this Security Statement plus the Privacy Policy. As the team grows we will document role-specific access matrices.

The following state-changing events are recorded in the per-user audit log with a 12-month rolling retention: sign-in, Xero connect, Xero disconnect, scan run, action approved, subscription changed, account deleted, credits purchased, credits consumed, credits refunded. Each row carries the acting Cognito sub, the timestamp, the before/after JSON where relevant, and any correlation ID from the underlying provider.

You can request an export of your own audit log by emailing chris@digitaltactics.co.uk.

We are working toward Xero App Marketplace certification (in progress at time of writing) and comply with UK GDPR, the Data Protection Act 2018, and the Privacy and Electronic Communications Regulations 2003 (PECR).

Formal certifications (SOC 2, ISO 27001) are on the roadmap once revenue supports the audit cost. Our infrastructure sits on AWS, which holds SOC 1/2/3, ISO 27001, ISO 27017, ISO 27018 and PCI DSS certifications for the underlying services — see aws.amazon.com/compliance.

Security disclosures and DPO: chris@digitaltactics.co.uk.

Support inbox: support@customercompass.ai. Initial response within two business days (see §9).

Post: Digital Tactics Ltd, 5 Boundary Road, Hove, East Sussex, BN3 4EH, United Kingdom.

Related documents: Privacy Policy, Terms of Service.