How we secure Audit Drive today.

Infrastructure and hosting

Audit Drive runs on Amazon Web Services. The web app is Next.js; the core API is a FastAPI service on ECS Fargate behind an application load balancer; application state lives in PostgreSQL on Amazon RDS; files live in Amazon S3. Long-running AI and document work runs as AWS Step Functions orchestrating Python Lambda tasks. All of it is defined in Terraform, so an infrastructure change is a reviewed, version-controlled change like any other.

Each supported geography is an independent regional cell with its own sign-in, API, database, file storage, encryption keys and AI resources, in its own production AWS account. No customer data moves between cells. An organisation belongs to one geography and its users exist only in that deployment, reached through an explicit regional domain.

• Production runs in dedicated AWS accounts, separate from development and staging
• One production account per geography, with separate Terraform state per regional deployment
• A release is deployed to one geography at a time and verified before the next, to limit the blast radius of a bad release
• Routine production changes go through CI/CD pipelines, which authenticate to AWS with short-lived credentials via OIDC rather than stored keys

Data protection and encryption

Our information security policy commits us to protecting customer and platform information with appropriate technical and organisational controls, including encryption where required, and to applying regional data-storage and processing controls where a customer, law, regulator or contract requires them.

PostgreSQL is the source of truth for application state: engagements, requests, evidence metadata, workpapers, assessments, reports, versions, citations and audit events. S3 holds the source files and generated artefacts only. The AI retrieval index is never a source of truth. Meaningful edits to an assessment or a report create a new immutable version rather than overwriting the last one, so the history of a workpaper is preserved.

• Customer-managed AWS KMS keys encrypt the underlying data infrastructure, one key per environment
• Terraform state is kept in its own dedicated bucket, separate from application data
• Personnel are prohibited from routinely downloading production customer evidence, database exports or sensitive logs to their own devices; exceptions need documented approval, a retention period and secure deletion
• Development and testing use synthetic data; using production data in a test environment is prohibited by default and needs separate authorisation each time

Customer isolation

Keeping customer organisations apart is the control we have designed most deliberately, because it is the one an audit firm is right to ask about first. Our policy commits us to maintaining separation between customer organisations and preventing unauthorised cross-tenant access, and the architecture does that with more than one independent boundary, so a bug in application code is not enough on its own to cross organisations.

Sign-in establishes identity and carries an immutable organisation identifier. The API then enforces fine-grained permissions. Underneath that, each important data store has its own boundary: PostgreSQL row-level security on tenant-owned rows, so cross-organisation rows cannot be returned even if a query omits the tenant filter; S3 access only through a temporary role scoped by the organisation identifier to that organisation’s prefix; and a separate AI knowledge base per organisation.

• Three boundaries, independent of each other: row-level security in the database, scoped temporary credentials for files, and a separate AI index per organisation
• Inside an organisation, permissions are enforced per auditee company and per audit, so people see the engagements they are on
• Asynchronous AI jobs carry the organisation, company, audit and initiating user throughout the workflow, and use the same boundaries as the API
• Tenant isolation is tested in a staging environment built from the same Terraform module as production, and that test has to pass before a release is promoted

AI and your data

Audit Drive’s AI runs on Amazon Bedrock, with Bedrock Knowledge Bases for retrieval, inside the same regional cell as the rest of your data. Where data has to stay in a particular region, inference is configured to stay in that region too.

The MVP has no model training or fine-tuning pipelines of any kind. That was a deliberate architectural decision, taken partly to avoid introducing further data-protection, residency and tenant-isolation concerns: Amazon SageMaker is explicitly out of scope for the MVP. Retrieval is scoped to a knowledge base belonging to your organisation, with filtering by company and audit inside it.

• No model training or fine-tuning pipelines in the MVP, by design
• A separate knowledge base per organisation — stronger isolation than we apply to ordinary application data
• Every AI call goes through one shared internal library, which records the model, the feature, the organisation, the initiating user, the job and the tokens used against that call
• AI output is a version of a workpaper that an auditor reviews and edits; a new version is created rather than the previous one overwritten
• Our own staff are prohibited from putting customer information, sensitive logs or secrets into AI tools we have not approved

Access and identity

Sign-in, password reset and multi-factor authentication are handled by Amazon Cognito, one user pool per regional environment, behind our own API: the web app never talks to Cognito directly, which keeps permission and region handling in one place. Multi-factor authentication is set up from an authenticator app or a text message, with recovery codes.

Our policy is to restrict access to information and systems by business need, role, organisation and least privilege. Inside the product, roles and access grants are held in the database and enforced by the API per auditee company and per audit. Behind the product, the rule is that nobody has standing administrative access to production.

• Engineers have no standing administrative access to production; only designated platform administrators can reach it with elevated privileges, in short-lived sessions that are reviewed
• Human access to AWS is through IAM Identity Center with named identities and multi-factor authentication; long-lived credentials are not used
• Emergency access is logged and reviewed afterwards; AWS CloudTrail records privileged administrative activity, logs are protected from modification or deletion, and significant privileged activity raises an alert
• Direct access to production databases and customer files is restricted to authorised operational need
• Access is reviewed periodically, and must be revoked on departure or a change of role
• Every device used to reach our code, infrastructure or customer information must have full-disk encryption, lock after five minutes, run a supported operating system with automatic security updates, and use a password manager and multi-factor authentication on critical systems

Security programme and certifications

Audit Drive is not certified against any security standard, and we will say so plainly until we are. Our security programme is built around alignment with ISO/IEC 27001:2022 — the standard many of our customers audit against — and we maintain a Statement of Applicability against it.

The programme is deliberately documented rather than assumed. We hold an Information Security Policy, an assignment of information security roles and responsibilities, an endpoint device security policy, a privileged access policy for production AWS, and product architecture documentation covering tenant isolation and data residency. In October 2026 we reviewed our repository, CI/CD and platform decisions line by line against the ISO 27002 guidance, recorded where they conform, listed the changes needed, named the work that has no owner yet, and formally recorded the risks we are accepting in the meantime.

• Security programme aligned to ISO/IEC 27001:2022, with a Statement of Applicability
• Policies are reviewed at least annually, and after significant architectural changes, incidents, regulatory or supplier changes, or risk assessment findings
• Security responsibilities are assigned to roles — management, a security and technical owner, engineering, product, and all personnel — rather than to particular individuals
• Security controls are built into how we ship: author and approver are always different people, independent acceptance is required before production, and secret, static analysis, dependency and infrastructure scanning gate every change
• Security documentation is available to customers and prospects on request

Incident response

Our information security policy commits us to identifying, assessing, responding to and learning from security incidents and weaknesses, and to recording and monitoring security-relevant activity so that an incident can be investigated. Everyone with access to Audit Drive information or systems is responsible for reporting a suspected weakness, event or incident.

The procedure we have written in most detail covers a lost, stolen or compromised device, and it shows the shape we apply: report immediately to the security and technical owner, contain access by revoking sessions, tokens and accounts, rotate the credentials that were actually exposed, then investigate — review the access logs, assess whether customer data could have been exposed, document what was done and determine whether anyone needs to be notified. Access is restored only once the device is recovered and verified, or replaced.

• A single named role, the security and technical owner, oversees security issues and incidents and tracks the actions arising
• Assessing potential customer-data exposure, and whether notification is required, is a defined step of the response, not an afterthought
• Privileged administrative activity is recorded in CloudTrail, with logs protected against unauthorised modification or deletion, so there is a record to investigate
• Device security incidents are logged in a register, with the response actions and the closure recorded, and secrets kept out of it

What we're working on next

This is the open list, taken from the gaps our own conformance review and policy drafts record. It is here because a security page that only lists strengths is not much use to an auditor.

• Approve the policy set and assign a named owner to each policy
• Close the eight changes the October 2026 conformance review identified, including preventing privileged users from stopping or deleting audit logs, attaching AI worker functions to the private network, restricting each account to its own region, and blocking the creation of long-lived AWS credentials
• Write the backup and recovery plan, with recovery objectives and a scheduled restore test, and a key-management procedure with annual key rotation
• Finish hardening the sign-in service: password policy, lockout, compromised-credential detection, session timeout and log-on logging
• Route security alerts to a named responder with a backup
• Publish a vulnerability disclosure contact and policy
• Commission an independent penetration test
• Set a records retention schedule, name a privacy owner, and complete a privacy impact assessment
• Complete supplier assessments, including of the AI tooling we build with, and keep a supplier register with the assurance obtained from each
• Verify the production readiness checklist before any customer data is processed
• Post-MVP: per-organisation cryptographic isolation, field-level encryption of sensitive data, client-side encryption of evidence, and support for connecting your own single sign-on