Security, compliance and data residency
The controls a customer switches on themselves, encryption and keys, patch targets by CVSS, security incidents and breach notification, customer penetration testing, ASK governance decisions, residency, and the evidence a customer can ask for.
Three layers of defence
| Prevent | Detect | Correct |
|---|---|---|
| Network isolation and WAF; HTTPS-only ingress; private database | Centralised logging — application, audit, cloud | Air-gapped backups; immutable vault; clean-room restore |
| Encryption at rest and in transit | Vulnerability scanning — images, dependencies, cloud configuration | Incident response runbooks and escalation |
| Granular RBAC, SSO, MFA, least privilege | Runtime threat detection | Live DR — a running second region with automatic failover |
| Hardened images; vulnerability and patch management |
Controls the customer switches on
Mapped to NIST CSF, most controls are built into TRANXACT or come from the cloud provider’s native services. Four are optional or the customer’s, and need saying out loud because nobody else will do them:
| Control | Function | Who |
|---|---|---|
| Data classification | Identify | The customer classifies personal and regulated data (INFRA_2.5.04 for retention and legal hold) |
| SSO and MFA through the IdP | Protect | The customer maintains accounts and the MFA policy in its IdP (PLAT_5.6.02); TRANXACT sets up federation (PLAT_5.6.01) |
| Customer-managed keys | Protect | Optional (TO_4.5.10); the customer runs the key lifecycle (TO_4.5.11) |
| SIEM integration | Detect | Log export is Optional (TO_4.6.02); operating the SIEM is the customer’s (TO_4.6.03) |
Encryption and keys
| What | How |
|---|---|
| Data in transit | TLS 1.2+ |
| Database at rest | AES-256 |
| Object storage and backups | AES-256 |
| Secrets | A managed secrets store |
| AI keys | The tier provider’s key, or BYOK |
| Certificates | A public CA for the FQDN |
- Standard: cloud KMS keys managed by TRANXACT, with defined rotation and destruction; no operator read access to keys; key access logged; vault backup keys held separately (TO_4.11.02).
- Optional: customer-managed keys in the customer’s KMS, customer-supplied certificates, BYOK for the ASK engine.
With customer-managed keys, revoking the key makes TRANXACT unavailable. Agree rotation and emergency procedures jointly before the key is used.
Patching by severity (proposed default)
| Severity (CVSS) | Remediation target | Customer notice |
|---|---|---|
| Critical (9.0–10) | Emergency path, as soon as a tested fix exists | Immediate, if downtime is needed |
| High (7.0–8.9) | Next maintenance window | Release notes |
| Medium (4.0–6.9) | Within 30 days | Release notes |
| Low (below 4.0) | Next scheduled release | Release notes |
Four stages: assess and classify; test and verify on non-production against a production-size copy; deploy by rolling update after the cooling period, watching health and ledger checks; respond and remediate. Customers with their own change boards should agree the notice period and which fixes may bypass it.
Security incidents and personal-data breaches
Control → Report → Declare → Resolve → Learn: contain and isolate; log and alert SecOps and the Autonomous Operations Pilot; classify and open a security incident; eradicate, restore from a clean state and verify the ledger; review the root cause and update controls and runbooks.
| TRANXACT — processor (TO_4.5.06) | Customer — controller (TO_4.5.07) |
|---|---|
| Confirms a breach affecting customer personal data | Assesses the risk to data subjects |
| Notifies the customer without undue delay, as set in the DPA | Notifies the supervisory authority where required |
| Shares the facts known, the likely impact and the measures taken | Informs affected data subjects where required |
| Provides updates as the investigation progresses | Records the breach in its own register |
Agree the notification contacts, channel and timeline in the DPA, and rehearse the communication plan with the customer’s DPO.
The customer’s own penetration test
- Sign an NDA.
- Request it at least 2 weeks ahead (TO_4.5.08, Additional Service).
- Agree the scope.
- Test non-production first — refreshed from production with data masking. Production testing needs explicit TRANXACT approval and a named window.
- Share the findings.
- Remediate jointly: platform findings are Standard (TO_4.5.09); findings in the customer’s own configuration are theirs.
| In scope | Out of scope |
|---|---|
| Application testing through the customer FQDN | Denial-of-service and load attacks |
| Authentication, authorisation and role design | Cloud-provider infrastructure |
| APIs used by the customer’s integrations | Other tenants, the vault account and shared tooling |
| Customer-side network paths (VPN, private link) | Social engineering of TRANXACT staff |
ASK governance decisions
ASK acts through TRANXACT’s APIs with the user’s own session, so every posting rule, role permission and audit-log entry applies as if the user had clicked. What is decided per customer:
| Decision | Category | R&R |
|---|---|---|
| Engine tier (premium, balanced, economy) and processing region | Standard, service request | ASK_6.1.02 |
| Connect a customer-provided AI key (BYOK) | Standard, service request | ASK_6.1.03 |
| Provide and rotate the BYOK key; hold the AI provider contract | Excluded | ASK_6.1.04 |
| Which roles may use ASK; usage budgets and alerts; monthly prompt and usage review; adoption sessions | Packaged — G1 ASK Usage Governance | ASK_6.2.01 – 6.2.03, 6.2.07 |
| Every ASK action in the audit trail | Standard | ASK_6.2.04 |
| The customer’s internal AI usage policy | Excluded | ASK_6.2.05 |
Data residency
- The primary region is where the ledger and documents live.
- The Live DR region and the vault sit in the same legal jurisdiction where regulation requires it.
- ASK: where prompts and responses are processed — BYOK if the customer mandates its own AI contract.
- Languages, entities, currencies and local statutory needs per legal entity.
- Sector rules: health records (EHR), student records, payroll and tax data.
- Cross-border transfers are covered by the DPA.
Confirm regulated-data requirements before choosing regions. Moving a live ledger between regions is a migration project.
Evidence and certifications
- On request: the security whitepaper and control descriptions, penetration-test summaries, switchover drill and clean-room restore reports, availability and backup-status reports, the sub-processor list and DPA TOMs (TO_4.5.12).
- The customer’s security due-diligence questionnaire, answered once per contract year (TO_4.5.13).
- Audit rights as defined in the DPA; the customer’s own penetration testing under the agreed process; log export to its SIEM.
Only quote certifications and attestations — ISO/IEC 27001, SOC 2 Type II, sector frameworks — whose current scope covers the customer’s cloud and region. Confirm with TRANXACT compliance before they go into a proposal.
Values marked proposed default are the deployment guide’s recommended starting points. Confirm each one per customer; the contract, order form, SLA and DPA prevail over this page.