Compliance

Where Vaethra stands, framework by framework

Framework	Status	Detail
SOC 2 (Security, Availability, Confidentiality)	Controls implemented Attestation in progress	Vaethra's security programme is built to the AICPA Trust Services Criteria, and the control map in §2 sets out each criterion against where it is implemented. A Type II attestation requires an audit observation window, which is under way; the report will be provided under NDA when issued.
ISO/IEC 27001:2022	Controls implemented Certification in progress	The information security management system is built to the Annex A control set, mapped in §3. Certification by an accredited body is in progress. Vaethra is not yet certified and does not claim to be.
GDPR / UK GDPR	Compliant	Vaethra Technologies LLC is established in the United States and processes personal data falling under the GDPR as a processor for its customers. A Data Processing Agreement is available at /legal/dpa, incorporating the 2021 Standard Contractual Clauses and the UK Addendum. Article-by-article mapping in §4.
CCPA / CPRA	Compliant	Vaethra does not sell or share personal information as those terms are defined. There is no advertising, no data broker and no cross-context behavioural profiling.
PCI DSS	Out of scope	Vaethra never receives, transmits or stores cardholder data. Invoicing is by bank transfer, and any future card payment would be handled entirely by a PCI-compliant processor.
HIPAA	Out of scope	Vaethra does not process protected health information and does not sign Business Associate Agreements. The public epidemiological feeds we read carry no individual health data.
NIS2	Aligned	Vaethra is not established in the EU and is not an in-scope essential or important entity under any national transposition. Where a customer is, our notification timelines are set to support their reporting obligations — see incident response.
EU AI Act	Limited risk, disclosed	Language models are used for text extraction, relationship assessment and embedding. No biometric processing, no automated decisions about individuals, no emotion recognition. Model output is labelled as model output wherever it appears. See architecture §4.
TISAX, FedRAMP, IRAP, C5	Not held	Not held and not currently in progress. If one is a requirement for your organisation, raise it early and we will give you a straight answer on scope and timing.

Each Trust Services Criterion, and where it is implemented

Read against the 2017 Trust Services Criteria (2022 revision). Every row links to the page that describes the control in full, so this table can be used as an index rather than as a summary.

CC1 — Control environment

Criterion	How it is met	Where
CC1.1 Integrity and ethical values	Written code of conduct and confidentiality undertaking signed before any access is granted	Security §7
CC1.2 Board oversight	The engineering owner is accountable for security; the risk register is reviewed quarterly and after any incident	Security §9
CC1.3 Structures and reporting lines	Security ownership, escalation path and named contacts documented	Security §9–10
CC1.4 Competence	Background checks for roles with production access; security responsibilities set out in engagement terms	Access control §5
CC1.5 Accountability	Individual accounts only, no shared credentials; every change attributable in version control	Development §2

CC2 — Communication and information

Criterion	How it is met	Where
CC2.1 Quality information	Health, status and uptime answered by the running system on public endpoints; per-source health published	Status
CC2.2 Internal communication	Findings delivered to an on-call channel on state change, with a daily summary of anything open	Availability §3
CC2.3 External communication	This trust centre; incident communication commitments; 30 days' subprocessor notice; 90 days' API deprecation notice	Trust centre, Support §5

CC3 — Risk assessment

Criterion	How it is met	Where
CC3.1 Objectives specified	Security objectives documented in the information security policy	Policy set, under NDA
CC3.2 Risks identified and analysed	Risk register: risk, likelihood, impact, owner, treatment	Register, under NDA
CC3.3 Fraud risk considered	Assessed as part of the register; separation of read and write paths; no payment handling in scope	Register, under NDA
CC3.4 Significant change assessed	Risk reviewed on architecture change and after every incident	Security §9

CC4 — Monitoring of controls

Criterion	How it is met	Where
CC4.1 Ongoing evaluations	Four layers of monitoring, including automated integrity checks that test whether controls are still working rather than whether jobs completed	Availability §3
CC4.2 Deficiencies communicated	Alerts on state change to the on-call channel; findings summarised publicly on the status page	Status

CC5 — Control activities

Criterion	How it is met	Where
CC5.1 Control selection	Controls selected against the risk register and implemented in code where possible rather than in policy	Development §4
CC5.2 Technology controls	Deny-by-default database authorisation, licence filtering in a shared query builder, fail-closed authorisation and caching	Security §5, Data protection §2
CC5.3 Policies and procedures	Documented policy set covering access, change, incident, cryptography, vendors and continuity	Policy set, under NDA

CC6 — Logical and physical access

Criterion	How it is met	Where
CC6.1 Logical access security	MFA required on every administrative account with no exception process; API keys stored as SHA-256 digests; row-level security deny-by-default on all 50 tables	Access control §1–2
CC6.2 Registration and authorisation	Access granted at minimum level for the role; production access not granted by default; keys issued individually with scope	Access control §3
CC6.3 Access modification and removal	Quarterly access reviews; revocation within one business day of a departure and immediately on an involuntary one, with credential rotation	Access control §4–5
CC6.4 Physical access	No Vaethra-operated facilities. Inherited from Cloudflare and AWS.	Security §8
CC6.5 Asset disposal	No physical media held. Disposal is performed by the infrastructure providers under their own attestations.	Data protection §5
CC6.6 External threat protection	Web application firewall, bot management and DDoS protection at the edge; per-caller rate limiting; no public database listener	Architecture §7
CC6.7 Transmission and movement of data	TLS 1.2 minimum with HSTS; restricted egress; extracts served through the API rather than from a public bucket	Data protection §3
CC6.8 Malicious software prevention	No general-purpose compute to infect; immutable deployments; pinned dependencies with continuous scanning; commit scanning for credentials	Vulnerability management §1

CC7 — System operations

Criterion	How it is met	Where
CC7.1 Vulnerability detection	Continuous dependency scanning; configuration review; automated integrity checks in production	Vulnerability management §1, §3
CC7.2 Monitoring for anomalies	Health, source, job and data integrity monitoring; rate-limit and authorisation failure logging	Availability §3
CC7.3 Security event evaluation	Three-level severity model with defined acknowledgement windows	Incident response §1
CC7.4 Incident response	Six-step process: declare, contain, notify, investigate, remediate, report	Incident response §3
CC7.5 Recovery from incidents	Immutable rollback in about a minute; restore procedure with integrity verification before recovery is declared	Business continuity §4

CC8 — Change management

Criterion	How it is met	Where
CC8.1 Change authorisation and testing	Six gates: branch, type check, 985 automated tests, review, immutable deploy, post-deploy verification. Database changes are versioned migrations recorded in a ledger.	Development §1–2

CC9 — Risk mitigation

Criterion	How it is met	Where
CC9.1 Business disruption mitigation	Stateless global edge, isolated data sources, encrypted backups, committed recovery objectives, annual DR exercise	Business continuity
CC9.2 Vendor and partner management	Subprocessors assessed before engagement and reviewed annually; contractual terms no weaker than those we give customers; 30 days' notice of change	Subprocessors §3–4

A1 — Availability, C1 — Confidentiality

Criterion	How it is met	Where
A1.1 Capacity management	Storage headroom and growth measured continuously from observed data rather than assumed; edge caching absorbs load spikes	Availability §2
A1.2 Backup and recovery infrastructure	Encrypted backups stored separately from the primary; independent raw archives with a second provider; infrastructure reproducible from source control	Business continuity §1
A1.3 Recovery testing	Rollback exercised continuously; restore tested to a scratch instance with a written report; annual DR exercise	Business continuity §5
C1.1 Confidential information identified	Four-class data classification with defined handling for each	Data protection §1
C1.2 Confidential information disposed of	Deletion within 30 days of a verified request across primary storage and caches; backups age out within the retention window	Data protection §5

The 2022 control set, by theme

Annex A of ISO/IEC 27001:2022 groups 93 controls into four themes. The rows below cover the controls applicable to Vaethra's scope; controls relating to facilities we do not operate are marked as inherited from the infrastructure providers, each of which publishes its own attestations — listed per provider on /security/subprocessors.

A.5 — Organisational controls

Control	How it is met	Where
A.5.1 Policies for information security	Documented policy set, reviewed at least annually and after any incident	Policy set, under NDA
A.5.2 Information security roles	The engineering owner is accountable; responsibilities set out in engagement terms	Security §9
A.5.7 Threat intelligence	Provider advisories, dependency advisories and CISA KEV monitored; CISA KEV is itself one of our ingested sources	Vulnerability management §1
A.5.8 Security in project management	Security review is part of the change process rather than a separate gate	Development §1
A.5.9–5.11 Asset inventory, acceptable use, return of assets	Asset register maintained; acceptable use in the policy set; offboarding removes device access and company data	Access control §5
A.5.12–5.14 Classification, labelling, transfer	Four-class classification; every record carries its source and licence; transfer restricted by class	Data protection §1, §2
A.5.15–5.18 Access control, identity, authentication, rights	Least privilege, individual identities, MFA everywhere, quarterly review	Access control
A.5.19–5.22 Supplier relationships	Subprocessors assessed before engagement, contractually bound, reviewed annually, and published	Subprocessors
A.5.23 Cloud services security	Two providers, both attested; configuration reviewed; no self-managed infrastructure	Security §2
A.5.24–5.28 Incident management	Documented process with severity model, notification deadlines, evidence preservation and post-incident report	Incident response
A.5.29–5.30 Continuity and ICT readiness	Committed recovery objectives, five documented scenarios, tested restore	Business continuity
A.5.31–5.34 Legal, IP, records, privacy	Licence classification enforced in code and database; GDPR programme; statutory records retention	Data protection, Privacy
A.5.35–5.37 Review, compliance, procedures	Quarterly review of this documentation and of access; control-by-control mapping maintained here	This page

A.6 — People controls

Control	How it is met	Where
A.6.1 Screening	Background checks for roles with production access, to the extent applicable employment law permits	Access control §5
A.6.2 Terms and conditions of employment	Confidentiality undertaking signed before access is granted	Security §7
A.6.3 Awareness and training	Security responsibilities in engagement terms; practice documented in the repository alongside the code	Development §4
A.6.5 Responsibilities after termination	Access revoked within one business day, credentials rotated, record kept	Access control §5
A.6.7 Remote working	Full-disk encrypted, screen-locked endpoints; no production data stored locally	Security §8
A.6.8 Reporting security events	Published reporting address and disclosure process with commitments	Vulnerability management §5

A.7 — Physical controls

Control	How it is met	Where
A.7.1–7.14 Physical perimeter, entry, equipment, media, disposal	Inherited. Vaethra operates no data centre, office server or physical infrastructure. Cloudflare and AWS hold ISO 27001, ISO 27017 and SOC 2 attestations covering these controls.	Security §8
A.7.7 Clear desk and clear screen	Endpoint screen lock enforced; no printed material	Security §8
A.7.9 Security of assets off-premises	Full-disk encryption on all endpoints; access through the same authenticated paths as any other client	Security §8

A.8 — Technological controls

Control	How it is met	Where
A.8.1 User endpoint devices	Encrypted, screen-locked, no production data at rest	Security §8
A.8.2–8.5 Privileged access, information access, source code, secure authentication	One production access holder; deny-by-default database authorisation; MFA everywhere; source access individually identified	Access control
A.8.6 Capacity management	Storage headroom and growth measured from observed data	Availability §2
A.8.7 Protection against malware	No general-purpose compute; immutable deployments; pinned dependencies	Vulnerability management §1
A.8.8 Management of technical vulnerabilities	Continuous scanning with severity-based patch windows: 24 hours critical, 7 days high, 30 days medium, 90 days low	Vulnerability management §2
A.8.9 Configuration management	All configuration in version control; deployments immutable and versioned; database schema as ordered migrations	Development §2
A.8.10 Information deletion	Deletion within 30 days of a verified request; backups age out	Data protection §5
A.8.11 Data masking	Local development uses synthetic fixtures rather than a copy of production; API keys stored only as digests	Development §3
A.8.12 Data leakage prevention	Licence filter enforced in the shared query builder and independently in the database, with an automated leakage probe	Data protection §2
A.8.13 Information backup	Continuous backup with daily snapshots, encrypted, stored separately; restore tested	Business continuity §1
A.8.14 Redundancy	Stateless globally distributed edge; automatic routing around a failed location	Availability §2
A.8.15–8.16 Logging and monitoring	API request logging retained 12 months; source, job and integrity monitoring; alerting on state change	Security §6
A.8.17 Clock synchronisation	Platform-managed time on all compute; every record carries both the source's timestamp and ours	Data protection §1
A.8.19–8.20 Software on operational systems, network security	No operating system to manage; WAF, bot management and DDoS protection at the edge; no public database listener	Architecture §7
A.8.21 Security of network services	All service-to-service traffic over TLS with secret-gated authorisation and a fixed operation allowlist	Architecture §1
A.8.22 Segregation of networks	Production, preview and local separated; preview and local have no production data binding	Architecture §2
A.8.23 Web filtering	Restrictive Content-Security-Policy on every page; no third-party scripts beyond the platform's own	Architecture §5
A.8.24 Use of cryptography	TLS 1.2+ in transit, AES-256 at rest, SHA-256 for credential digests; documented cryptography policy	Data protection §3
A.8.25–8.29 Secure development lifecycle	Secure coding standard, review, 985 automated tests including tests that assert controls refuse, static type checking, environment separation	Development §1, §4
A.8.30 Outsourced development	Not applicable — development is not outsourced	—
A.8.31 Separation of environments	No shared staging environment holding production data	Development §3
A.8.32 Change management	Six gates, immutable versioned deployments, rollback in about a minute	Development §1–2
A.8.33 Test information	Synthetic fixtures only; production data is never copied into a test environment	Development §3
A.8.34 Protection during audit testing	Audit access arranged in advance with scope agreed; scanning against production coordinated rather than ad hoc	DPA §9

Where each obligation is discharged

Article	Obligation	How it is met
Art. 5	Principles	Data minimisation is architectural — no accounts, no cookies, no profiles. Purpose limitation and storage limitation documented per category. Privacy §2
Art. 6	Lawfulness	A lawful basis stated for every category of processing. Privacy §2
Art. 12–22	Data subject rights	Access, rectification, erasure, restriction, portability and objection, answered within one month. Privacy §5
Art. 24, 32	Controller responsibility, security	Technical and organisational measures documented in full. DPA §14
Art. 25	Data protection by design and default	No accounts, no cookies, no third-party trackers, self-hosted fonts. There is no setting that turns tracking on. Privacy §1
Art. 28	Processor obligations	Executable DPA with subprocessor terms, audit rights and deletion obligations. DPA
Art. 30	Records of processing	Maintained; available under NDA. Privacy §6
Art. 33–34	Breach notification	72 hours to the supervisory authority and to affected customers, with the Article 33(3) content. Incident response §4
Art. 35	Impact assessments	Carried out where processing is likely to be high risk; the enterprise workspace will be assessed before it ships. Privacy §6
Art. 37	Data protection officer	Not required: core activities do not involve large-scale systematic monitoring of individuals or special-category data. The founder is accountable. Privacy §6
Art. 44–49	International transfers	2021 Standard Contractual Clauses and the UK Addendum, with supplementary measures and government-access commitments. DPA §10–11

Four things, on request

1. This documentation, as a single PDF — sixteen pages covering what a standard vendor security review asks, including the control maps above, with the cross-references intact.
2. Your questionnaire, completed in writing. CAIQ, SIG Lite or a bespoke spreadsheet. Typical turnaround five business days.
3. The evidence pack, under NDA — policies, risk register, access-control evidence, recovery test results, vendor assessments. Listed in full on the trust centre index.
4. A call with the engineer who built the system, who can answer architecture questions directly.

↓Security & Compliance PackageEvery trust-centre page in one file, cross-linked, for attaching to a review or handing to a model.PDF · 64 sheets · 1280 KB

If a specific certification or artefact is a condition of purchase, raise it on the first call and we will give you a date or a straight answer that we cannot meet it. Tell us what you need.