Noetis — Security & Compliance Addendum

Version 1.0 · Effective date: 19 June 2026 · Last updated: 2026-06-19

This Addendum describes the security programme for the Noetis Service. It forms part of the Terms and supports Annex II of the DPA. Noetis may update controls so long as the overall level of protection is not materially reduced.

1. Security governance

Noetis maintains a written information-security programme proportionate to the nature of the Service and the data processed, owned by Noetis management, with documented policies for change management, incident response, disaster recovery, key rotation, data retention and access review (maintained in docs/).

2. Encryption

• In transit: all connections use TLS 1.2+ (HTTPS) enforced by the platform.
• At rest: data stores are encrypted at rest using AES-256 (platform level).
• Application-level field encryption: particularly sensitive fields —

including third-party OAuth tokens and submitted PII — are additionally encrypted at the application layer (AES-256-GCM) with keys held separately from the database.

3. Access control & authentication

• RBAC: role-based access control with least-privilege roles; every data

operation is subject to ownership/permission checks.

• MFA: multi-factor authentication is available and enforced/step-up for

sensitive operations and privileged users.

• Tenant isolation: logical isolation enforced in the data layer (database

row-level security / ownership policies on tenant tables) and the application layer; a build-blocking test prevents any new endpoint from accessing a tenant resource without an authorisation gate.

• Administrative access to production is restricted to authorised personnel,

on a need-to-know basis, and logged.

4. Logging, monitoring & audit

• Audit logging: an append-only audit trail records security- and

data-relevant actions (who, what, when, before/after), exportable for review.

• Structured logging to a log drain enables search, alerting and retention.
• Monitoring: scheduled-job liveness/watchdog checks and anomaly alerting;

loud alerts on supplier/billing exhaustion and security-relevant events.

• Rate limiting and an application-layer WAF screen abusive traffic.

5. Secure development (SDLC)

• Version-controlled change management with mandatory type checks and an

automated test suite (1,000+ tests) gating merges.

• Automated route-security conventions test fails the build unless every API

route has a recognised authentication/authorisation gate or a documented public-by-design exemption.

• Input sanitisation for AI-generated content (prompt-injection screening; CSS

rule break-out and injection blocked; size/count caps) before content reaches storage, stylesheets or render.

• Dependency vulnerability scanning in CI; secrets kept out of source control.

6. Vulnerability & patch management

• Dependencies are monitored and updated; high-severity advisories are

prioritised.

• A coordinated vulnerability disclosure policy is published (SECURITY.md):

reports to chris@noetis.nl, acknowledgement target of 2 business days, coordinated disclosure window.

• A third-party penetration test is scoped (docs/PENTEST_SCOPE.md) and will be

performed as the programme matures; summaries available to enterprise customers under NDA when completed.

7. Resilience: backups & disaster recovery

• Backups: managed, encrypted database backups with point-in-time recovery

capability provided by the data platform.

• Disaster recovery: documented DR procedures (docs/DISASTER_RECOVERY.md)

with recovery objectives; the platform runs on resilient managed infrastructure (Vercel, Supabase) with provider-level redundancy.

8. Incident response

• Documented incident-response runbook (docs/INCIDENT_RESPONSE.md) covering

severity classification, containment, forensics order, and breach-notification timelines.

• Personal data breaches affecting Customer Personal Data are notified to

affected customers without undue delay (see DPA §7).

• Supplier/provider errors (e.g. AI provider outages) are handled so that

internal/supplier issues are not leaked to end users.

9. Personnel

Personnel with access to production or customer data are bound by confidentiality and receive security guidance appropriate to their role. Access is provisioned on the principle of least privilege and reviewed periodically.

10. Sub-processor security

Sub-processors are engaged under contracts requiring appropriate security measures (see DPA Annex III). Noetis selects providers (Vercel, Supabase, OpenAI, Anthropic, Stripe) that maintain recognised security programmes.

11. Data segregation, retention & deletion

Customer data is logically segregated by tenant. Retention follows the schedule in docs/DATA_RETENTION.md. Customers can export their data in-product and delete their account; deletion removes or de-identifies personal data except where retention is legally required.

12. Compliance posture

• GDPR/AVG: the Service is designed for GDPR compliance (see Privacy Policy

and DPA).

• SOC 2: a SOC 2 readiness package and control-to-criteria mapping is

maintained (docs/SOC2_READINESS.md); formal audit is planned as the company matures. This Addendum does not itself constitute a SOC 2 report.

• Noetis will share reasonable security documentation with enterprise customers

under NDA on request.

13. Customer responsibilities

Security is shared. Customer is responsible for: safeguarding credentials and enabling MFA; configuring roles and optimisation boundaries; obtaining required consents/notices from its End Users; the content it publishes; and the lawful use of the Service.

Security contact: chris@noetis.nl