Security

Request-path cryptography

Every mutating request to api.iso-compliant.com must carry one of three authentication forms:

1. A detached Ed25519 signature in X-Iso-Compliant-Signature over the canonicalised request body, with the key id in X-Iso-Compliant-Key-Id;
2. HTTP Message Signatures per RFC 9421 with Signature-Input and Signature headers covering the request target, content-digest, and date derived components;
3. A bearer API key in the Authorization header with prefix iso_live_ (production) or iso_test_ (sandbox). The full token is sha-256 hashed; only the prefix and hash are stored.

Signature verification runs before any business logic. Failures return 401 SIGNATURE_INVALID or 401 INVALID_API_KEY; no information about the rest of the request payload is leaked in the failure response.

Zero-retention payment payloads

The transformation pipeline is stateless. Plaintext payment payloads are processed in-memory and discarded; only the SHA-256 hash, the derived MsgId, the response status, and the ruleset version are persisted (for idempotency + audit). Plaintext payloads expire from the request-render cache within five minutes of response.

Hash-chained audit attestation

Every successful mutating request emits an audit row containing the SHA-256 of the canonical response XML chained to the prior tenant audit row's hash. The chain is tamper-evident: any retroactive modification of a single entry invalidates every subsequent entry. Customers may export the chain as part of the Evidence Pack and verify it independently against the per-call X-Iso-Compliant-Sha256 response header.

Idempotency

Every mutating endpoint requires X-Iso-Compliant-Idempotency-Key (min 8 chars). The server hashes the canonical request body and stores the response for seven years. A replay with the same key and matching body returns the original response byte-identical; a replay with the same key and a different body returns 409 IDEMPOTENCY_CONFLICT. This guarantees that retry-storm conditions cannot result in duplicate payment files being submitted to the bank.

Network and storage

• TLS 1.3 in transit; HSTS with preload on all production hosts;
• Postgres at-rest encryption via the Supabase volume layer (AES-256-GCM);
• Per-tenant KMS-encrypted payload in the human-in-the-loop retry queue; ciphertext only at rest;
• All Customer data stays inside the customer's elected region by default (EU-Frankfurt unless an alternative is pinned on the order form); no cross-border egress in the request path.

Programme

• Multi-factor authentication mandatory for all iso-compliant team members on every administrative system;
• Least privilege via short-lived role assumption for production access; access logged to the same hash-chained audit infrastructure used for Customer data;
• Quarterly external penetration testing. Executive summary available to Customers under NDA;
• Dependency security: Dependabot grouped weekly, high-severity SCA alerts within 24h, license-fence (no GPL-class in production binaries);
• Backups: Supabase point-in-time recovery + weekly logical dump to a separate region. RPO 15 minutes, RTO 4 hours.

Compliance status

• SOC 2 Type 1 — readiness from month 3 of GA;
• SOC 2 Type 2 — audit window opens month 9;
• ISO 27001 — certification programme begins month 14;
• GDPR, UK Data Protection Act 2018, and Swiss nFADP — operating commitments in the DPA.

Disclosure policy

We welcome coordinated security disclosure. Send any finding to security@iso-compliant.com (PGP key forthcoming). Acknowledgement within 72 hours. Bounty bands:

• Critical — pre-auth RCE, signing-key extraction, cross-tenant data leak: $25,000;
• High — post-auth privilege escalation, audit-chain tamper, signature-bypass: $5,000;
• Medium — IDOR on non-payment data, deserialisation, sensitive logging: $1,000;
• Low — accepted-but-cosmetic findings: $250.

Safe-harbour: good-faith research under this policy will not be met with legal action.

Contact

Security: security@iso-compliant.com