Security Policy

1. Our Security Commitment

At Circinova, security is not an afterthought — it is a core design principle of everything we build. Our platform handles sensitive compliance data, integration credentials, and cloud configuration information on behalf of our customers. We recognise that this places a significant responsibility on us to protect that data and to maintain the trust of the organisations that rely on us.

This document describes Circinova's security practices, infrastructure controls, and processes for managing vulnerabilities and incidents. It is intended for customers, prospective customers, and security researchers who want to understand how we protect data and how to engage with us responsibly on security matters.

For questions or concerns not addressed in this document, please contact security@circinova.com.

2. Infrastructure Security

2.1 Cloud Platform

Circinova's infrastructure runs exclusively on Amazon Web Services (AWS) in the us-east-1 (N. Virginia) region. All customer data is stored and processed in the United States. We do not operate any on-premises infrastructure. Transfers of personal data from UK or EEA users to Circinova's infrastructure are covered by appropriate safeguards as described in our Privacy Policy and Data Processing Agreement.

2.2 Network Isolation

All production workloads run within a dedicated Amazon Virtual Private Cloud (VPC) with strict inbound and outbound traffic controls enforced via AWS Security Groups and Network ACLs. Public-facing components (load balancers and API gateways) are isolated in public subnets, while application servers and database instances are deployed in private subnets with no direct public internet access. All internet traffic is routed through managed load balancers and ingress controllers, and all outbound traffic from application containers is subject to egress filtering.

2.3 Compute

Application workloads run on AWS ECS Fargate, a serverless container execution environment. Fargate eliminates the need for Circinova to manage underlying EC2 instances, reducing the attack surface associated with unpatched host operating systems. Container images are scanned for known vulnerabilities before deployment, and only approved images from our private container registry are permitted to run in production.

2.4 Database Security

Customer compliance evidence and account data are stored in AWS RDS PostgreSQL instances. All RDS instances are deployed in private subnets, accessible only from application containers within the same VPC. Encryption at rest is enabled using AWS KMS-managed keys. Automated backups are taken daily and stored for 7 days. Point-in-time recovery is enabled on all production database instances. Database access credentials are rotated regularly and stored in AWS Secrets Manager.

2.5 Object Storage

Files and artefacts are stored in AWS S3 buckets. Server-side encryption is enabled on all S3 buckets using AES-256 (SSE-S3) or AWS KMS-managed keys (SSE-KMS) as appropriate to the sensitivity of the data. Public access is blocked at the bucket level for all buckets containing customer data. Pre-signed URLs with short expiry times are used for any customer-facing file access.

3. Data Encryption

3.1 Encryption at Rest

All customer data stored by Circinova is encrypted at rest using AES-256 encryption:

• Database data (AWS RDS PostgreSQL): encrypted using AWS KMS-managed keys, applied at the storage layer.
• Object storage (AWS S3): encrypted using SSE-S3 (AES-256) or SSE-KMS as appropriate.
• Integration credentials (GitHub OAuth tokens, AWS IAM access keys): additionally encrypted at the application layer using Fernet symmetric encryption before being persisted to the database. Fernet encryption keys are stored in AWS Secrets Manager, not alongside the encrypted credentials.

This layered approach means that even in the event of a database compromise, integration credentials remain encrypted and cannot be decrypted without access to the separately held application-layer keys in AWS Secrets Manager.

3.2 Encryption in Transit

All communications between users and the Circinova platform, and all internal service-to-service communications, are encrypted using TLS 1.2 or higher. TLS 1.0 and TLS 1.1 are explicitly disabled. HTTP requests are redirected to HTTPS with HSTS (HTTP Strict Transport Security) headers enforced. TLS certificates are managed via AWS Certificate Manager and are automatically renewed before expiry.

3.3 Key Management

Encryption key management is centralised in AWS Secrets Manager and AWS KMS. Encryption keys are never stored in application code, environment variables, or version control. All key material is subject to automatic rotation policies, and access to key management services is restricted to authorised Circinova infrastructure automation and engineering personnel.

4. Access Controls

4.1 Role-Based Access Control

Access to the Circinova Service is governed by role-based access controls (RBAC). Within a customer organisation, administrators can assign roles (such as Owner, Admin, Member, and Auditor) to users, with permissions granted on a least-privilege basis appropriate to each role.

4.2 Multi-Factor Authentication

Multi-factor authentication (MFA) is required for all Circinova engineers and staff who access production systems, cloud management consoles, and internal tooling. We strongly recommend that all customers enable MFA on their Circinova accounts; where supported by the Service, MFA can be enforced at the organisation level by an administrator.

4.3 Least-Privilege IAM

Our AWS infrastructure is governed by IAM policies that follow the principle of least privilege. Each service, microservice, and Circinova engineer is granted only the minimum permissions required to perform their specific function. IAM roles are used in preference to long-lived IAM user credentials wherever possible. Long-lived credentials (such as those required for specific integration patterns) are stored exclusively in AWS Secrets Manager and rotated regularly.

4.4 No Shared Credentials

Circinova does not use shared credentials for any access to production systems. All access is individually attributable to a specific engineer or service identity. Shared accounts are not permitted.

4.5 Access Reviews

Circinova conducts quarterly reviews of all personnel access to production systems and cloud resources. Access for former employees and contractors is revoked within 24 hours of their departure.

5. Penetration Testing

Circinova engages an independent, CREST-qualified security testing firm to conduct a comprehensive penetration test of our infrastructure, application, and APIs at least once per year. The scope of the test includes our web application, API endpoints, authentication mechanisms, network perimeter, and cloud configuration.

Upon completion of each test, Circinova reviews and remediates all findings in accordance with our vulnerability management SLAs (see Section 6). A summary of our most recent penetration test, including the testing firm's name, test date, and a high-level scope summary, is available to Growth plan customers and Enterprise customers upon request under a mutual non-disclosure agreement. Contact security@circinova.com to request this information.

6. Vulnerability Management

6.1 Dependency Scanning

Circinova uses GitHub Dependabot and additional static analysis tooling to continuously monitor all software dependencies (including third-party libraries in our backend and frontend applications) for known security vulnerabilities. Dependabot automatically opens pull requests to update vulnerable dependencies, which are reviewed and merged by our engineering team.

6.2 Container Image Scanning

All container images used in production are scanned for OS-level and package-level vulnerabilities before deployment using AWS ECR image scanning. Images with critical or high-severity vulnerabilities are blocked from deployment until remediated.

6.3 Patching Service Level Agreements

We apply the following SLAs for patching vulnerabilities in our systems:

| Severity | Definition | Patching SLA | |----------|-----------|-------------| | Critical (CVSS 9.0–10.0) | Exploitable vulnerability with potential for significant data breach or service compromise | 24 hours | | High (CVSS 7.0–8.9) | Exploitable vulnerability with meaningful but contained impact | 7 calendar days | | Medium (CVSS 4.0–6.9) | Vulnerability requiring specific conditions to exploit | 30 calendar days | | Low (CVSS 0.1–3.9) | Minimal impact or very difficult to exploit | 90 calendar days |

These SLAs apply to vulnerabilities in Circinova's own systems and code. For third-party dependencies, we apply the same SLAs from the date a patch becomes available from the upstream maintainer.

7. Incident Response

7.1 Incident Response Process

Circinova maintains a documented security incident response plan that is reviewed and tested at least annually. The plan covers: incident detection and classification; escalation and communication procedures; containment and eradication; recovery; and post-incident review.

7.2 Customer Notification

In the event of a security incident that affects the confidentiality, integrity, or availability of customer data, Circinova will notify affected customers without undue delay and in any event within 72 hours of becoming aware of the incident. Notification will be sent to the email address associated with the customer's account and will include: a description of the incident and the data affected; the steps Circinova is taking to contain and remediate the incident; and advice for any actions the customer should take.

7.3 Incident Notifications

Circinova communicates incident updates via email to affected customers. To report an incident or subscribe to notifications, contact support@circinova.com.

8. Responsible Disclosure and Bug Bounty

8.1 Reporting Security Vulnerabilities

Circinova encourages security researchers and members of the public to report potential security vulnerabilities in our Service. If you believe you have discovered a security vulnerability, please report it to us responsibly:

Email: security@circinova.com Subject: Vulnerability Report — [brief description]

Please include in your report: a description of the vulnerability and its potential impact; detailed steps to reproduce the issue, including any relevant URLs, payloads, or screenshots; and your contact details so we can follow up with you.

8.2 Our Commitment to Reporters

Circinova commits to the following for good-faith security researchers:

• We will acknowledge receipt of your report within 5 business days.
• We will investigate and assess the report promptly and keep you informed of our progress.
• We will not initiate legal action against you for good-faith security research conducted in accordance with this policy.
• We will work with you to understand and remediate the vulnerability before public disclosure.
• Where you are the first to report a novel, exploitable vulnerability, we will acknowledge your contribution (with your permission) in our security acknowledgements.

8.3 Scope

The following are in scope for responsible disclosure:

• The Circinova web application at circinova.com and app.circinova.com
• Circinova's public APIs
• Authentication and authorisation mechanisms

The following are out of scope:

• Denial-of-service attacks or tests designed to degrade service availability
• Social engineering or phishing attacks against Circinova staff
• Physical security testing
• Automated vulnerability scanning without prior written authorisation
• Issues in third-party software or services not controlled by Circinova

8.4 Bug Bounty

Circinova currently operates a discretionary reward programme for significant, novel vulnerabilities. Rewards are assessed on a case-by-case basis according to the severity and exploitability of the reported vulnerability. To discuss eligibility, contact security@circinova.com.

9. Compliance

9.1 SOC2 Type II

Circinova is actively working towards SOC2 Type II certification. We are implementing the Trust Services Criteria across our organisation, including Security, Availability, and Confidentiality criteria. We use our own platform to collect and manage evidence for our SOC2 programme.

Our target date for completing an initial SOC2 Type II period is communicated to interested customers on request. Contact security@circinova.com for updates on our certification status.

9.2 ISO 27001

ISO 27001 certification is on our product roadmap. We are aligning our information security management system (ISMS) with ISO 27001:2022 requirements as part of our broader security programme.

9.3 UK GDPR

Circinova is registered with the Information Commissioner's Office (ICO) under registration number pending registration — see ico.org.uk. Our data processing practices comply with the UK GDPR and the Data Protection Act 2018. For details, please see our Privacy Policy at circinova.com/legal/privacy and our Data Processing Agreement at circinova.com/legal/dpa.

10. Contact

For all security-related enquiries, vulnerability reports, and requests for security documentation:

Circinova (sole trader) — Security Team Email: security@circinova.com United Kingdom