Security Statement

This document describes the technical and organisational security measures we implement to protect the Noryn platform and the personal data processed within it, as required by Article 32 UK GDPR.

1. Encryption

1.1 Data in transit

• All connections to the platform use TLS 1.3 (minimum TLS 1.2)
• HTTP Strict Transport Security (HSTS) is enforced
• Certificates are managed by Vercel with automatic renewal

1.2 Data at rest

• Database storage is encrypted at rest using AES-256 (Supabase default)
• OAuth tokens and integration credentials are additionally encrypted at the application layer using AES-256-GCM before storage
• Because that application-layer encryption happens before the data is written, the database stores only ciphertext — so a backup contains no readable OAuth token or integration credential, and the key that decrypts them is held in our server environment and is never written to the database or into a backup
• Backups themselves are the automatic snapshots taken by Supabase, our database provider. Their storage encryption is Supabase’s control, described in its own security documentation; we rely on it and are not in a position to verify it independently

2. Access Control

• Role-based access control (RBAC): Customers have roles within their organisation (Owner, Admin, Member). Admin and platform staff have separate elevated roles.
• Row-Level Security (RLS): Every database table has Row-Level Security enabled, with policies scoped to the organisations a signed-in user belongs to. This is what constrains anything holding a customer’s own credentials — including the browser — and for those paths isolation is enforced by the database itself.
• Service role: Our own server code mostly connects with a service-role key that bypasses RLS, because much of what the platform does legitimately crosses tenants (payment webhooks, scheduled jobs, the administration console). Two rules make that safe, and both are enforced in our own code rather than by the database: authorisation is established before the connection is used, and every query carries an explicit organisation filter. See §3.
• The service-role key never leaves the server: it is not exposed to the browser, to customers, or to any client-side code.
• MFA for the administration console: reaching Noryn’s internal admin pages or admin API routes requires a session that has completed a second factor, and every administrative action additionally requires an enrolled factor.
• Principle of least privilege: Staff access is scoped to what is necessary for their role, and the administration console is limited to platform administrators. We do not currently require recorded justification for direct access to the production database, and such access is not written to our own audit log — §8 sets out what that log does and does not cover.

3. Tenant Data Isolation

Two different mechanisms keep one customer’s data away from another, and it is worth being clear about which does what.

• Anything holding a customer’s credentials — their browser, or any request made with their session — is constrained by database Row-Level Security. A query for another organisation’s rows returns nothing, and no application mistake can widen that.
• Noryn’s own server code mostly uses a service-role connection that bypasses RLS, because much of the platform legitimately works across tenants. Here isolation is enforced in our code: the caller’s authority is established first, and every read, write and delete carries an explicit organisation filter. A missing filter would be a cross-tenant defect rather than something the database would refuse, so the rule is documented at the point the connection is created, and this class of mistake is the first thing our security reviews look for.

The service-role key is held only in the server environment and is never exposed to the browser, to customers, or to any client-side code.

4. Backups and Recovery

• The database is backed up automatically every day
• Point-in-time recovery is available where enabled on the database tier
• Restores follow a documented internal runbook

5. Sub-processor Security

This table covers our largest sub-processors. The complete, current list — including providers without a published certification — is at /legal/sub-processors. Certifications: Anthropic, Supabase, Stripe, Vercel, Resend.

6. Incident Response

6.1 Detection

Our detection is error reporting rather than continuous monitoring, and we would rather be exact about it than imply a capability we have not built:

• Server-side failures are written to a platform errors table that an administrator can browse, filter by source and mark resolved.
• The first failure from a given source sends one email to our operations mailbox. Further failures from that same source are recorded without another email for six hours, so that an incident cannot bury the rest of the day’s alerts.
• Every scheduled job records a heartbeat when it completes. Our health endpoint reports the platform as degraded when a job has not run within twice its expected interval, or when the database cannot be reached.
• Requests to public endpoints — webhooks, the booking API, the chat widget — are rate-limited per source. A request that fails signature verification is recorded as an error (rate-limited so that one sender cannot fill the table), though a request merely turned away by the rate limit is not itself recorded.

What this is not. We do not operate automated anomaly or intrusion detection, we do not have a 24-hour on-call rotation, and we do not run a separate review process for security events as distinct from other errors. Alerts reach a single operations mailbox and are acted on during working hours. Our health endpoint reports status when it is asked; it is not continuously polled by an external monitor. Reports from customers and security researchers (§7) are therefore a real part of how we find problems, and we treat them accordingly.

6.2 Breach notification

In the event of a personal data breach:

• We will assess the breach within 24 hours of detection
• We will notify affected Customers within 48 hours of becoming aware
• We will notify the ICO within 72 hours where the breach poses a risk to individuals (as required by UK GDPR Article 33)
• We will notify affected data subjects where the breach poses a high risk to their rights and freedoms (Article 34)
• A full incident report will be provided to affected Customers within 14 days of resolution

6.3 Incident logging

All security incidents are logged in our internal incident tracker with timeline, scope, root cause, and remediation actions. Records are retained for 6 years.

7. Vulnerability Disclosure

If you discover a security vulnerability in the platform, please report it responsibly:

• Email: security@norynsystem.com
• Include: description of the vulnerability, steps to reproduce, potential impact
• Do not exploit the vulnerability or access data belonging to other customers
• We will acknowledge reports within 48 hours and keep you updated on remediation progress
• We will not take legal action against security researchers acting in good faith

8. Audit Logs

Actions taken by Noryn platform administrators against a customer’s organisation are recorded in an audit log that the platform only adds to: no part of the product can edit or remove an entry, and the only process that ever modifies one is the scheduled anonymisation described below. Every entry records who acted (or that the event was reported by a system rather than a person), the action, what it was taken against, and when. Where the code performing the action captures them, an entry also carries the previous and new values and a stated reason; many actions record the action and its target only, so a before-value is not available for every entry. The log covers:

• Changes an administrator makes to a virtual employee: pausing, resuming, deleting and restoring it, and editing, regenerating, test-running or applying its instructions
• A virtual employee being submitted for review, approved, rejected, or going live
• Tier changes and subscriptions created by an administrator
• Refunds and disputes reported by our payment provider
• Suspension and restoration of an organisation
• Team membership: invitations sent and revoked, members removed, and role changes
• Creation and revocation of API keys, and deletion of an uploaded document
• Conversations flagged for attention, and administrator notes created, edited and deleted
• Privacy request outcomes, data export requests, resolved plan-change requests, and platform and feature flag changes
• Prompt templates created and updated

Actions this log does not record. We would rather name these than let the list above be read as exhaustive: tool permission decisions and tool approvals or rejections; a member of our staff taking over a conversation, or editing a message; deletion of an organisation as a distinct event (erasure is recorded through the privacy request that caused it); credits and discounts; subscriptions paused or cancelled; and integrations connected, disconnected or reconfigured. Noryn has no facility for staff to sign in as one of your users, so there is no such event to log.

Entries are retained for 24 months. After that the record of the action is kept as the compliance artefact while the personal data around it — IP address, browser, and the before and after values — is removed.

What this log does not cover: changes a customer makes inside their own dashboard are not written to it, and read-only support access by our staff is not recorded as a separate entry. Where an administrator changes something while assisting a customer, that change is logged as above.

Which routes to production data this covers. Our administration console is the route this log describes, and reaching it requires a platform administrator account with multi-factor authentication. It is not the only route: our operators can also reach the production database directly through our database provider’s own tooling, which this application does not mediate and this log does not record. That access is held by a small number of people and used for maintenance such as applying database migrations. We are not claiming more for it than that.

Customers can request their organisation’s administrator audit log through the privacy requests tool at /dashboard/privacy/requests.

9. Secure Development

• Automated checks. Type checking, our automated test suite and linting run on every change pushed to the main branch and on every pull request. These checks are advisory rather than blocking: our hosting provider builds from the same change independently, so a failing check does not by itself prevent a release. We treat a failure as something to fix immediately.
• Code review. The platform is built by a very small engineering team, and we do not operate a mandatory second-reviewer gate before deployment — so we do not claim independent pre-deployment review. What we do instead, and will stand behind: security-relevant areas — tenant isolation, authentication, and the handling of credentials and customer data — are reviewed against the code deliberately and periodically, and what those reviews find is corrected in the code and written into this documentation. Several statements on this page are narrower than they once were for exactly that reason.
• Dependencies. We do not currently run automated dependency vulnerability scanning. Dependencies are kept current and updated when we become aware of an advisory affecting one. Introducing automated scanning is on our roadmap alongside the certification work in §10.
• Secret management. All credentials and encryption keys are supplied through the server environment and are never committed to source control or hardcoded, and they are never sent to the browser.

10. Certifications Roadmap

We intend to pursue SOC 2 Type II certification as we scale. Until that certification is obtained, this Security Statement and our sub-processors’ certifications serve as the primary security documentation. Enterprise customers may request a security questionnaire by emailing security@norynsystem.com.