Security and Compliance Controls
The controls that support HIPAA, GDPR and similar programmes: encrypted secrets, credential redaction, a database per tenant, the audit trail, self-hosting, and the security add-on's framework evidence. Plus the record-keeping API and what it does not do.
Overview
Shift-Left API does not make an organisation HIPAA or GDPR compliant, and it holds no SOC 2, ISO 27001 or HIPAA attestation of its own. What it gives regulated teams is a set of security and data-handling controls that keep sensitive material safe while you test, and evidence your auditors can use. There is no HIPAA or GDPR module to switch on: the controls below are part of the platform. Explore the capability at security & compliance controls.
Availability: encryption, redaction, tenant isolation and self-hosted deployment apply on every plan. Configurable audit retention, the activity feed, SSO, groups, secret managers and the self-hosted LLM are Enterprise and Trial. The framework evidence view comes with the API Security Testing add-on (included in the Trial).
Controls that protect sensitive data
| Control | What it does |
|---|---|
| Secrets encrypted at rest | Auth-profile credentials, data-source and dataset secret fields, webhook signing secrets, secret-manager configuration, SSO client secrets and SP keys, users' AI keys, licence keys and SIEM or ticketing credentials are encrypted with AES-256-GCM using envelope keys. The key-encryption key is wrapped by a key bound to the installation, so the keystore file or the database alone cannot decrypt them. An optional recovery passphrase is available. |
| Credential redaction | Authorization-type headers are redacted in captured request diagnostics before they are stored, and before they leave the local runner. Audit snapshots blank any field whose name looks like a password, secret, API key or token. |
| Database per tenant | On the hosted service each customer organisation has its own database and subdomain. See multi-tenant architecture. |
| Access control | Five built-in roles with per-project overrides control access to the gated screens and routes; see Role Permissions for what is enforced. SSO configuration with group-to-role mapping is covered in Single Sign-On (SSO). |
| Secrets kept in your vault | On Enterprise and Trial, auth profiles and requests can reference secrets in HashiCorp Vault instead of storing them. See Secret managers. |
| Self-hosted deployment | Install the platform on your own infrastructure against your own MongoDB, so test definitions, payloads and run results stay in your network. On Enterprise and Trial, AI features can use a self-hosted model (Ollama, LM Studio or vLLM) under Settings → Integrations → AI Settings, so specs and prompts are not sent to a third-party model provider. See AI settings. |
| Opt-in telemetry | Usage telemetry is off by default, carries no personal data, and can be exported to a file instead of sent. |
What is not field-encrypted: test definitions, request and response bodies and run results. Their protection at rest depends on how the database is deployed (disk or database encryption on your MongoDB, or the hosted service's storage). If your tests carry real personal or health data, prefer synthetic data, or self-host and encrypt the database.
Evidence for your audits
- Audit trail. Changes to tests, endpoints, projects, users, roles and settings are recorded with the user, time, IP address, device and before and after values. Retention is 90 days by default; Enterprise and Trial can choose 30, 90 or 365 days or unlimited. See Audit Logs.
- Framework view (API Security Testing add-on). Security findings roll up by OWASP API Security 2023 category against 11 frameworks: PCI DSS 4.0, SOC 2, ISO 27001:2022, NIST SSDF, GDPR, HIPAA, NIS2, DORA, NIST SP 800-53, EU CRA and CMMC. Each control is cited, not reproduced, and the view states that it is evidence of testing, not a certification. The add-on also checks API responses for exposed personal data and secrets. See API Security Testing.
- Requirement evidence. The requirements traceability matrix shows, per requirement, its tests, their latest runs and whether the requirement was actually verified.
Record-keeping API (no screen)
The backend also exposes record-keeping routes under /api/compliance/* (GDPR) and /api/hipaa/* (HIPAA). No screen in the app uses them; they can only be called directly with a signed-in token, and every call writes an audit event. Administrative calls need the access_settings_section permission.
| Area | What the API records |
|---|---|
| Consent and privacy preferences | Consent by type (marketing, analytics, essential, third_party, data_processing) and the signed-in user's privacy preferences. |
| Data-subject requests | A user can file an access request or an erasure request, and an administrator can set its status and response text. Filing or completing an erasure request deletes nothing and exports nothing: it is a tracking ticket. Deleting or exporting the data is a separate, manual task. |
| Breach records | An administrator can record a breach against a user record. |
| HIPAA records | A generic patient-record store with authorizations, PHI access logs, breach records, BAA records, safeguards and a per-patient JSON report. It records only what you post to it and is not connected to tests, payloads or runs. |
The API does not detect or flag personal or health data in test payloads, generate HHS notifications, or produce a compliance report for regulators.
Troubleshooting / Notes
- "Where do I enable HIPAA or GDPR mode?" There is no such setting. The controls above are always on, or are configured in the screens linked from each row.
- Access denied on an admin call to the record-keeping API: you need access_settings_section.
- Account deletion: an administrator can delete a user. Comments, memberships and audit rows keep the username, so the audit history stays intact.
- Pair this page with Role Permissions and Audit Logs when you prepare evidence for an audit.
Related articles
Previous
Local Runner
Product documentation
Next
Activity Feed and One Signed-In Machine per User
Product documentation
Related articles
- Administration Settings · Product documentation
- Server Connection · Product documentation
- Proxy Settings · Product documentation
- License Management: Status and Keys · Product documentation
- User Management · Product documentation
- Role Permissions · Product documentation
Next steps
- Getting started · Install + connect your spec
- Configuration fundamentals · Stabilize runs
- Initial configuration · Users, licensing, projects
- Release notes · Updates and fixes
Still stuck?
Tell us what you’re trying to accomplish and we’ll point you to the right setup—installation, auth, or CI/CD wiring.