Security

AuditPath is built to handle sensitive compliance data. We implement security controls aligned with SOC 2 Type II criteria — the same standard we help our customers achieve. This page documents our security practices transparently.

If you are a security researcher and have found a vulnerability, please see the Report a Vulnerability section below.

Cloud Provider

AuditPath runs entirely on Amazon Web Services (AWS) in the Asia Pacific (Mumbai) region (ap-south-1), keeping customer data within India by default.

Compute

• Backend: AWS ECS Fargate — serverless containers, no SSH access to underlying hosts
• Frontend: Vercel Edge Network — globally distributed, TLS-terminated at the edge
• Containers are deployed from immutable images tagged to git commit SHAs

Database

• AWS RDS PostgreSQL in a private VPC subnet — not publicly accessible
• Automated backups with 7-day retention
• Storage encrypted at rest using AES-256
• Row-Level Security (RLS) enforced at the database level for tenant isolation

File Storage

• Evidence files stored in Amazon S3 with server-side encryption (SSE-S3)
• Buckets are private — all access via pre-signed URLs with short expiry windows
• No public S3 bucket access

In Transit

• All traffic between clients and AuditPath is encrypted using TLS 1.2 or higher
• HTTPS enforced on all endpoints — HTTP requests are redirected
• API traffic between frontend and backend uses TLS via the Application Load Balancer
• HSTS headers enforced on the production domain

At Rest

• RDS database volumes: AES-256 encryption via AWS KMS
• S3 evidence files: AES-256 server-side encryption
• Passwords: bcrypt with cost factor 12 — never stored in plaintext
• JWT tokens: short-lived (15 minutes) access tokens, rotated refresh tokens

Role-Based Access Control (RBAC)

AuditPath enforces four role tiers with granular permissions:

• OWNER — full administrative control, billing, organisation management
• ADMIN — team management, integrations, portal creation
• MEMBER — evidence upload, control updates, read access
• AUDITOR — read-only access via time-limited portal tokens

Principle of Least Privilege

Every role has access only to what it needs. Role checks are enforced at both the API layer (Spring Security @PreAuthorize) and the database layer (Row-Level Security policies).

Internal Access

• No employee has direct access to customer data in production
• Database access requires MFA and a time-limited access request
• All production access is logged and auditable

• Backend runs in a private VPC subnet — not directly reachable from the internet
• All inbound traffic routed through an AWS Application Load Balancer (ALB)
• Security groups restrict port access — only 80/443 open on the ALB
• Database accessible only from within the VPC (no public endpoint)
• ECS tasks communicate with RDS via private IP
• CORS configured to allow only auditpath.io and localhost (development)

Every customer organisation is completely isolated from others at the database level using PostgreSQL Row-Level Security (RLS). Every table that contains customer data includes an org_id column and a corresponding RLS policy.

The current organisation's ID is set as a session variable on every database connection before any query executes. This means it is architecturally impossible for one organisation to read or modify another organisation's data, even if there were an application-level bug.

When you connect your AWS account to AuditPath, we use a cross-account IAM role with the following security controls:

• Read-only access only — AuditPath never writes to or modifies your AWS resources
• External ID condition on the trust policy prevents confused deputy attacks
• Minimum necessary permissions — scoped to IAM, EC2, S3, RDS, CloudTrail
• Role ARNs are stored encrypted and never exposed in API responses
• You can revoke access at any time by deleting the IAM role

• Email verification required on registration before login is permitted
• Passwords hashed with bcrypt (cost factor 12)
• JWT-based authentication — stateless, short-lived access tokens (15 min)
• Refresh token rotation — tokens are single-use and invalidated after use
• Logout invalidates the current access token immediately
• Rate limiting on login and registration endpoints to prevent brute force
• Account lockout after repeated failed login attempts

• Dependencies reviewed regularly and updated for known CVEs
• Docker base images kept up-to-date with security patches
• CI/CD pipeline includes build-time dependency scanning
• OWASP Top 10 considered in all feature development
• SQL injection prevented by parameterised queries via JPA/Hibernate
• XSS prevented by React's default output escaping

In the event of a security incident affecting customer data, we commit to:

• Notify affected customers within 72 hours of becoming aware of the breach
• Provide a clear description of what data was affected and what we are doing about it
• Work with affected customers to mitigate impact
• Conduct a post-incident review and share learnings where appropriate

• Background checks for team members with access to production systems
• MFA required on all internal tooling and cloud console access
• Security awareness training for all team members
• Offboarding checklist ensures immediate access revocation on departure

We take security reports seriously. If you discover a vulnerability in AuditPath, please disclose it responsibly:

• Email: security@auditpath.io
• Include a description of the vulnerability and steps to reproduce
• We will acknowledge your report within 48 hours
• We ask that you do not publicly disclose the issue until we have had a chance to address it

We do not currently offer a bug bounty programme, but we will publicly acknowledge responsible disclosures (with your permission) and work with you in good faith to resolve any issues quickly.