Most controls are built into TRANXACT or come from the cloud provider’s native services. The ones that fail in practice are the ones the customer has to switch on themselves, because nobody else will.
| Control | Customer’s part |
|---|---|
| SSO and MFA | Accounts and the MFA policy live in the customer’s IdP (PLAT_5.6.02). TRANXACT sets up federation. |
| SIEM | Log export is Optional (TO_4.6.02); operating the SIEM and its use cases is the customer’s (TO_4.6.03). |
| Customer-managed keys | Optional (TO_4.5.10); the key lifecycle, rotation and emergency procedures are the customer’s (TO_4.5.11). |
| Data classification | The customer classifies personal and regulated data and decides retention and legal hold. |
| Access recertification | Periodic, and the customer’s (PLAT_5.6.04). |
| Operator elevation | The customer approves it, and any co-signed access to production data (TO_4.5.05). |
Keys
TLS 1.2+ in transit; AES-256 at rest for the database, object storage and backups; a managed secrets store; cloud KMS keys managed by TRANXACT with no operator read access and vault keys held separately. Customer-managed keys, customer-supplied certificates and BYOK for ASK are options.
With customer-managed keys, revoking the key makes TRANXACT unavailable. Agree rotation and emergency procedures jointly before go-live.
Patching (proposed default)
| CVSS | Target | 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 |
A personal-data breach
TRANXACT is the processor: it confirms the breach, notifies the customer without undue delay as the DPA sets out, shares what is known and what was done, and keeps updating. The customer is the controller: it assesses the risk to data subjects, notifies the supervisory authority and the data subjects where required, and records the breach in its own register.
The customer’s penetration test
NDA; request 2 weeks ahead (an Additional Service for the coordination); agree scope; test non-production refreshed with masking first — production needs explicit approval and a named window; share findings; remediate jointly. Out of scope: denial of service and load attacks, the cloud provider’s infrastructure, other tenants, the vault account and shared tooling, and social engineering of TRANXACT staff.
ASK
ASK acts through TRANXACT’s own APIs with the user’s session, so every posting rule, permission and audit-log entry applies as if the user had clicked. Per customer: the engine tier and processing region, BYOK or not, which roles may use ASK, and usage budgets. Role policy and budgets are the G1 package or the customer’s; the AI provider contract under BYOK is the customer’s.
Only quote certifications whose current scope covers the customer’s cloud and region, and only after TRANXACT compliance has confirmed them.
Calderwood’s DPO asks who tells the regulator if payroll data leaks. Calderwood does — it is the controller. TRANXACT tells Calderwood, without undue delay and through the contacts named in the DPA.
Try it Calderwood wants to load-test production to "prove the WAF" as part of its penetration test. What is the answer?
Denial-of-service and load attacks are out of scope for a customer penetration test. Load testing is a separate thing: TRANXACT runs one on non-production at peak volume before go-live (TO_4.12.02, Standard), and further load tests are an Additional Service (TO_4.12.03).