CivilQuants — Security Exhibit

Effective date: 2026-05-31

Version: v1 (vault-drafted 2026-05-17; aligned with ToS v1.2 + Privacy Policy v1.2 + Customer DPA v1)

Last updated: 2026-05-17

At a glance

CivilQuants is built and operated by Ember Forge Pte Ltd, a Singapore-incorporated company (UEN 202617538C). This document describes the technical and organisational security measures we have in place to protect your data.

1. Encryption

1.1 In transit

All data in transit between your client and our Service uses TLS 1.3 (with TLS 1.2 fallback only where the client does not support 1.3). This covers:

• Browser ↔ web app (civilquants.com)
• REST API client ↔ API server (api.civilquants.com)
• MCP client ↔ MCP server (api.civilquants.com/mcp)
• Python SDK ↔ API server
• CLI ↔ API server

All data flowing between internal system components (application ↔ database, application ↔ object storage, application ↔ Sub-Processor APIs) is also TLS-encrypted.

1.2 At rest

• Primary database (Fly Postgres): AES-256-equivalent encryption at rest. Encryption keys managed by Fly.io.
• Object storage (Cloudflare R2): AES-256-equivalent encryption at rest. Encryption keys managed by Cloudflare.
• Backups: Encrypted at rest using the same standards as the primary stores.

Access to encryption keys is restricted to the same access-control regime as production-systems access (§2 below).

2. Access controls

2.1 Production-systems access

Production-systems access is granted on the principle of least privilege. At launch:

• Dave Irvine (Director, Data Protection Officer) — full production access for operational reasons.
• Future engineering function additions are granted under written confidentiality obligations and need-to-know-based access scopes.
• Personnel off-boarding revokes access within 24 hours of role end.

2.2 Multi-Factor Authentication (MFA)

MFA is required on all production-access accounts, including:

• Fly.io
• Cloudflare
• Stripe (admin)
• Clerk (admin)
• Sentry
• PostHog (admin)
• GitHub
• Any AWS / additional cloud-provider access if and when established

2.3 Audit logging

Significant production actions are logged. Audit-log retention: 24 months (per Privacy Policy §6).

The computational audit log of paid renders is a separate, append-only log retained for 7 years under a distinct legal basis (legitimate interest in the establishment, exercise, or defence of legal claims — UK / EU GDPR Article 6(1)(f) coupled with the Article 17(3)(e) exemption from the right of erasure; equivalent provisions in PDPA, PIPEDA, APP, Privacy Act 2020, and PDPA Malaysia). See Terms of Service §8.4 and Privacy Policy §6 for full treatment.

2.4 Session controls

• Session timeouts on production-admin sessions.
• Role-based access control on operator-side admin surfaces (when shipped per the operator dashboard roadmap).

3. Network and infrastructure security

3.1 Perimeter

Cloudflare is the perimeter network for all public-facing surfaces:

• DDoS protection — Cloudflare's enterprise-grade DDoS mitigation across the full attack-vector surface.
• Web Application Firewall (WAF) — rule sets including OWASP Core Rule Set, Cloudflare-managed rules, and custom rules as the threat surface evolves.
• Rate limiting at the edge — alongside the application-layer rate limiting we apply to API and MCP surfaces.
• Country-level egress controls — applied where appropriate to specific surfaces.

3.2 Application + database hosting

Fly.io hosts the application servers and the primary Postgres database in the London (LHR) region for v1.

• Single-tenant container isolation between Fly.io customers.
• Private networking between application containers and the Postgres database — the database is not exposed to the public internet.
• Region selection is set to LHR by default for v1 to keep UK/EU customer data within the UK/EU; future regional expansion will follow data-residency demand.

3.3 Object storage

Cloudflare R2 stores generated artefacts (Excel workbooks, DXF drawings, PDF deliverables) derived from your project inputs.

• Signed-URL access for artefact retrieval — no public-read buckets for customer-generated content.
• Signed URLs are time-limited to the duration needed for the customer to download the artefact.

3.4 Dependency security

• Automated dependency scanning in the CI pipeline (Renovate / Dependabot equivalent).
• Regular patching for known vulnerabilities in third-party dependencies.

4. Software development security

4.1 Code review

Code review by a second party (or a second LLM reviewer in cross-vendor adversarial mode) on all changes to security-sensitive code paths:

• Authentication and authorisation
• Payment and billing
• Data persistence
• Personal Data handling
• MCP serving and customer-LLM-mediated interactions

4.2 Pre-commit security review

• Security-reviewer agent runs on every high-risk merge.
• Cross-vendor adversarial review pass (currently using Codex as a second-opinion reviewer alongside the same-model security-reviewer) on the highest-risk merges.

4.3 CI gates

• Static analysis: ruff and mypy --strict for Python; tsc for TypeScript.
• Test coverage requirements (unit + integration + end-to-end).
• OPSEC regression tests preventing leakage of identifying substrings in customer-facing outputs.

4.4 Secrets management

• No secrets in source control. All secrets are loaded from environment variables or secrets-store.
• Rotation on any exposure event.
• Restricted-key isolation — payment-processor restricted keys are separated from full keys; webhook secrets are environment-isolated per environment (dev / staging / production).

5. Backups and recovery

• Encrypted backups rotated per the following schedule:
  • Incremental backups: maximum retention 30 days.
  • Full backups: maximum retention 90 days.
• Backup integrity testing at reasonable intervals to verify that backups can be restored.
• Disaster recovery posture: target RPO (recovery point objective) ≤ 24 hours for Customer Data processed in the preceding 7 days.
• Backups are encrypted at rest using the same standards as the primary stores.
• During the backup-retention window, Customer Data in backups is not processed for any purpose other than disaster-recovery integrity.

6. Personnel measures

6.1 Confidentiality

All personnel with access to Customer Data are bound by written confidentiality obligations.

6.2 Access scoping

Engineering personnel (current and future) are granted access on a need-to-know basis scoped to their role.

6.3 Off-boarding

On role end, access is revoked within 24 hours, including: production-systems access, code repository access, Sub-Processor admin-account access, and physical/device access to any company-issued equipment.

6.4 Security-awareness training

As the team grows, security-awareness training will be required for all personnel with access to Customer Data. At launch, the single-person production-access scope makes this training-target-of-one — Dave Irvine maintains current knowledge of UK GDPR, EU GDPR, PDPA, and operational-security best practice.

7. Sub-Processor management

7.1 Contractual safeguards

We have a written Data Processing Agreement (DPA) in place with each Sub-Processor before any Customer Data is shared. DPAs impose data-protection obligations substantially equivalent to those we owe you.

7.2 Periodic review

Sub-Processor security posture is reviewed at least annually, or upon material change in Sub-Processor status (e.g., the Sub-Processor announces a region change, a corporate restructuring, or a material security incident affecting customers more broadly).

7.3 Termination on material failure

We reserve the right to terminate a Sub-Processor engagement on material data-protection failure, and to migrate Customer Data to a replacement Sub-Processor under the change-notice mechanism set out in Customer DPA §6.2.

7.4 Public list

The full list of Sub-Processors — including each Sub-Processor's role, region of processing, transfer mechanism for UK / EU personal data, and the date we signed the corresponding DPA — is published at civilquants.com/legal/sub-processors.

8. Incident response

8.1 Playbook

We maintain an incident response playbook with notification timelines that meet:

• UK GDPR: notification to the UK ICO within 72 hours of becoming aware of a Personal Data Breach; notification to affected individuals where the breach is likely to result in a high risk to their rights and freedoms.
• EU GDPR: notification to the lead Supervisory Authority within 72 hours.
• Singapore PDPA: notification to the PDPC within 72 hours for "notifiable" data breaches.

8.2 Customer notification

For Personal Data Breaches affecting customer data, we will notify the affected customer (acting as Controller under Customer DPA §9) within 48 hours of becoming aware — a tighter window than the statutory 72-hour Supervisory-Authority window, so that the customer has reasonable time to meet its own statutory notification obligations.

8.3 Notification contents

Our breach notification will include, to the extent then known:

• Nature of the Personal Data Breach (categories and approximate number of Data Subjects + records concerned)
• Contact details of our Data Protection Officer (dpo@emberforge.sg)
• Likely consequences
• Measures taken or proposed to address the breach and mitigate its possible adverse effects

8.4 Post-incident review

Every incident triggers a post-incident review to identify and remediate the root cause and to update the playbook if needed.

9. Physical security

CivilQuants does not operate any physical premises hosting Customer Data. All hosting is via Sub-Processors with their own physical security controls (Fly.io data centres, Cloudflare edge network, AWS / GCP facilities used by Sub-Processors). Sub-Processors' physical security postures are verified by their published certifications (SOC 2, ISO 27001 where applicable).

Ember Forge Pte Ltd's registered office address is a commercial virtual office in Singapore (60 Paya Lebar Road, #06-28 Paya Lebar Square, Singapore 409051) used for company-registration and statutory-correspondence purposes only; no Customer Data is held at, processed at, or accessible from that address.

10. What we don't do

The following are stated explicitly because we are aware that procurement teams ask about them, and the absence of the practice is part of our security posture:

• We do not sell your data. Our revenue model is subscription / pass / module credits — directly from customers. Your data is not part of our revenue model.
• We do not train machine-learning models on your inputs in any way that could allow your specific project content to be recovered or attributed. Aggregate, irreversibly anonymised statistics may be produced per Privacy Policy §2.3 and (for B2B customers' third-party data) only on documented Customer DPA instruction per Customer DPA §5.
• We do not have a server-side LLM in the data path at v1. The CivilQuants engine is deterministic parametric computation. Your project inputs flow to the engine; outputs flow back. There is no LLM "reading" or "summarising" your project data on our servers in v1. Where you use the Service via an MCP-connected LLM client (Claude Desktop, ChatGPT, Cursor, Gemini, etc.), data you send to your LLM client is handled by your LLM client's provider per its own terms — see Privacy Policy §1.3.
• We do not have a third-party advertising network on the Service. No marketing cookies in v1; no advertising trackers; no third-party ad pixels.
• We do not use weak or deprecated cryptography. No TLS 1.0 / 1.1; no MD5 or SHA-1 in production code paths; no MD5-based passwords.
• We do not store payment card numbers. Stripe handles all cardholder data per PCI DSS; we receive only masked identifiers (last 4 digits, brand, expiry) for displaying the customer's default payment method.

11. Compliance posture and roadmap

11.1 Current state at launch

• UK GDPR + EU GDPR compliance — operationalised across the Privacy Policy, Cookie Policy, Customer DPA, this Security Exhibit, and the relevant engineering controls (consent gating, audit logging, breach notification, data-subject rights mechanism, sub-processor DPAs).
• Singapore PDPA compliance — Ember Forge Pte Ltd's home regulatory regime; Dave Irvine registered as the company's Data Protection Officer with the PDPC.
• Australia APP, New Zealand Privacy Act 2020, Canada PIPEDA (including Quebec Loi 25), Malaysia PDPA — operationalised at the framework level via Privacy Policy §5.4 country-specific transfer notes and the cross-jurisdiction warranty in the ToS.
• No SOC 2 or ISO 27001 certification at launch. These certifications are not held at v1 launch. Smaller customers do not typically require them; large-procurement Enterprise customers may.

11.2 Roadmap

• SOC 2 Type I → Type II: scoped for evaluation post-launch once recurring-revenue baseline justifies the audit cost (typical small-tech-SaaS SOC 2 readiness + audit: USD 30-80k Year 1; recurring USD 15-40k/yr). Trigger to evaluate: first 3 Enterprise procurement asks where SOC 2 is a stated requirement.
• ISO 27001: scoped for evaluation post-launch on similar trigger; ISO 27001 tends to be EU/SG procurement-preferred.
• Penetration testing: scoped for evaluation post-launch once the customer-facing surface and storage of B2B-customer project data is in production for ≥3 months. Target: independent third-party pentest by a CREST-accredited firm.
• Bug bounty: scoped for evaluation post first 50 active customers.

11.3 What we offer in lieu of certification at launch

• This Security Exhibit — full, operationally specific description of measures in place.
• The Customer DPA §10 audit-rights clause — you can audit us directly (1× per 12 months under standard terms) on reasonable notice.
• Sub-Processor certifications — we lean heavily on Sub-Processors that hold SOC 2 and/or ISO 27001 (Fly.io, Cloudflare, Stripe, Resend, Clerk, Sentry, PostHog all hold relevant certifications at the parent-company level).

12. Contact

For any question about this Security Exhibit, our security posture, or our compliance position:

• Data Protection Officer (DPO): dpo@emberforge.sg
• Security inquiries: security@civilquants.com (alias, routes to DPO)

For coordinated disclosure of a security vulnerability in CivilQuants, please contact security@civilquants.com directly rather than via public disclosure channels in the first instance. We will respond within 5 business days.

Related documents

• Terms of Service (v1.2) — including §8.4 hash cell + computational audit log
• Privacy Policy (v1.2) — including §6 retention + §7 security measures + §8 your rights
• Cookie Policy (v1.2)
• Customer DPA (v1, available on request) — including Annex 2 TOMs (this Security Exhibit is the public-facing reflection of Annex 2)
• Sub-Processors page (v1)