Do you have SOC 2 Type II or ISO 27001 today?

No. SOC 2 Type I is planned for 2027-05-31. SOC 2 Type II is planned for 2027-12-15, after a six-month observation window. ISO 27001 is planned for 2028-09-30. CCPA/CPRA compliance is an operational legal programme, not a certification. Current status always lives on the trust page. We will not send a SOC 2 in progress letter that implies a report exists.

Where is data stored, and are you multi-tenant?

A Hetzner data center in Nuremberg, Germany, on every tier; no other processing region is offered. Logical isolation on shared infrastructure, with a dedicated VPC or self-hosted on Enterprise. Every row carries a tenant id, and cross-tenant tests are part of release QA.

Is customer data used to train models?

No. Not by nox.markets, and not by the model subprocessors we route to, under the API terms we will actually sign. This is in the DPA, not only on the website.

What data do you send to OpenAI, Anthropic or Google, and do they keep it?

For products that use a model: the prompt, the retrieved context and the completion. Not OAuth tokens, not other tenants, not full system exports. We use no-training or zero-retention endpoints where they are offered. Providers may retain a limited slice for abuse monitoring even under zero retention, and we do not hide that. Below Scale we choose the vendor; the subprocessor list still names them.

Encryption at rest and in transit? Who holds the keys?

TLS 1.2 minimum and TLS 1.3 preferred in transit. AES-256 at rest. [PLACEHOLDER: key management on the Hetzner server — confirm at deployment] Application-level envelope encryption for connector secrets. We hold the customer master key at launch. Customer-managed keys are planned for Enterprise on 2027-06-30.

Google and Microsoft OAuth on Starter. SAML 2.0 on Growth and above. SCIM 2.0 on Scale and above. SSO can be forced. SCIM deprovisioning revokes sessions within 5 minutes.

What are the roles, and can your staff read our documents?

Three roles on Growth: owner, admin, member. Custom roles on Scale. Our staff have no standing access to run payloads. Break-glass access is ticketed, capped at 4 hours, requires MFA, and is logged. An Enterprise MSA can require that we notify you when payload is accessed.

Audit logs: what, how long, can we stream them to a SIEM?

Authentication, role changes, integration connect and revoke, runs as metadata plus a payload hash rather than a body, exports, and staff break-glass. Retention is 30 days on Starter, 12 months on Growth, 36 months on Scale and Enterprise. SIEM streaming is available on Scale and above.

Encrypted snapshots daily, continuous write-ahead log shipping, 35-day retention, stored in Germany. RPO and RTO are 24 hours and 8 hours on Starter and Growth, 1 hour and 4 hours on Scale, 15 minutes and 1 hour on Enterprise. Restores are tested quarterly; the first test is planned for 2026-12-31.

Independent penetration test?

Annual, web and API, starting with a first test planned for 2026-12-15. A letter of attestation can be public; the full report is under NDA on Scale and above. We do not publish a pentest PDF on a marketing page.

Vulnerability management and patching SLAs?

Critical, meaning actively exploited or CVSS 9 and above and reachable: 24 hours. High: 7 days. Medium: 30 days. Low: 90 days. Dependencies are scanned in CI, and containers for application services are rebuilt rather than patched in place.

Subprocessors, and how do we hear about changes?

The list is public and is the same table on this page and in the legal subprocessor page. We give 30 days notice before a new entity processes customer personal data, with a 15-day objection window for DPA customers. The SaaS tools we OAuth into on your behalf are your processors, not our subprocessors.

What happens to data when we cancel?

A 30-day export window for configuration and run history in open formats. Primary deletion by day 30; backups are gone by day 65. Connected OAuth grants are revoked, and work already written to your general ledger or CRM stays there. Self-hosted data is on your disk. A purchased one-time licence survives churn, but the data still follows this clock.

Incident notification timeline?

A personal-data breach is notified to the workspace owner no later than 72 hours after we confirm it. A P1 availability incident is notified within 24 hours and appears on the status page. We do not delay customer notice until a press release exists.

Background checks, MFA, and production access for your employees?

Background checks before production access where lawful. Hardware-backed MFA on our identity provider. Production and staging are separate, and production data is not copied to staging. Production access is a reviewed group, not everyone in engineering.

Security

What we read, where it runs, how long we keep it, and who can see it.

Customer data is not used to train models. Finance products default to human approval. SOC 2 Type II is in progress — we will not imply a report we do not have.

Request our DPA Book a demo

RegionHetzner, Nuremberg (Germany)

Disclosuresecurity@nox.markets

01 — Scope / 3 deployment models

US · EST. 2026

What this page covers, and what stays yours.

Your general ledger, CRM, HRIS, mailbox, and bank stay authoritative. We do not keep a second subledger of your business.

Region: A Hetzner data center in Nuremberg, Germany, on every tier. No other processing region is offered.
Tenancy: Logical isolation on shared infrastructure: a separate encryption context and a row-level tenant id on every customer table.
Enterprise tenancy: Dedicated VPC, or self-hosted in your own environment.
Systems of record: Yours. The invoice in QuickBooks is the invoice your customer got; we do not keep a parallel AR or AP ledger.
Payment cards: Never stored. Once checkout takes payment, Stripe processes cards as our payment processor. We hold the customer and subscription ids and the last four digits for display.
Training on customer data: Contractually forbidden, in the DPA, not only on this page.
Zero retention: An Enterprise option for run payloads. Every other plan follows the retention ladder below.

02 — Data classes / 8 classes

Every byte we persist belongs to one of these classes.

Product pages and the DPA inventory use the same names, so a questionnaire answer and a product page cannot describe different things.

Data classes nox.markets stores
Class	What it is	Stored on our infrastructure
account_data	Work email, display name, hashed password or identity-provider subject, billing email, Stripe customer id, company name, plan	Yes
workspace_config	Product mappings, schedules, approval matrices, templates, and price lists typed into a hosted tool	Yes
connector_secrets	OAuth refresh tokens, API keys pasted by the customer, bring-your-own-key model keys	Yes, encrypted as secrets — not plaintext in the application database
run_payload	The input document, prompt context, and model or tool output of a single run	Yes, unless zero-retention is on or the deployment is self-hosted
run_metadata	Run id, product slug, timestamps, status, credits consumed, SHA-256 of the payload, actor	Yes, even under zero-retention
audit_event	Who, what, when, from which IP, against which object id	Yes
support_data	Tickets and the screenshots a customer attached to them	Yes
telemetry_self_hosted	Licence check, version, heartbeat. No documents, no tokens, no prompts	Yes, in the licence service only

What we do not store

Full exports of a QuickBooks file, HubSpot portal, mailbox or drive. Only the objects a product pulled for a named run.
Card numbers, CVVs, or bank login passwords. Where Plaid is connected it holds the bank credentials; we receive the account and balance tokens the product is configured to read.
Biometric data, data about children, and — until a BAA is in force — protected health information. Acceptable use forbids those classes on every plan.
Fine-tuned model weights derived from a customer's documents.
A second copy of an invoice, bill or quote PDF after the workspace retention window, other than encrypted backups that age out on the same clock.

Until a business associate agreement is in force, protected health information is forbidden on every plan by the acceptable use policy. That is a product constraint, not a preference.

03 — Data flow / 3 models

Where the data goes depends on how the product is deployed.

The deployment model is on every product card in this language, not as jargon. Here is what each one means for your bytes.

hosted
runs on nox.markets
You type or upload into our app. The data lands in your workspace, is processed there, and the result stays in our app until you export it or a connected write-back exists. A quote builder that stores your price list and the finished PDF is the shape of it.
connected
runs on nox.markets, acts in your tools
You grant a scoped OAuth token. On the trigger you set, we pull the minimum objects the product's inputs require, process them — including, where the product uses a model, one call to a model subprocessor — write the outputs back to your system of record, and keep the run payload only for your workspace retention window.
You can revoke the grant in your identity provider or in the dashboard. We delete the stored connector_secrets within 24 hours of a revoke or disconnect.
self-hosted
you run it, we license it
Available on Enterprise. Your data does not enter nox.markets production at all. The licence service receives a check, a version, and a heartbeat — no documents, no tokens, no prompts.

04 — Retention / 10 artifacts

Retention is a workspace setting with a ceiling per plan.

Audit retention and payload retention are different clocks. An auditor asking who approved a bill needs the audit event; an auditor asking to see the PDF needs the payload still on disk.

Retention ceilings by plan
Artifact	Starter	Growth	Scale	Enterprise
run_payload default	30 days	30 days	90 days	90 days
run_payload maximum	30 days	365 days	365 days	365 days, or 0 days with zero-retention
run_metadata	30 days	12 months	36 months	36 months, or term plus 12 months by MSA
audit_event	30 days	12 months	36 months	36 months, or term plus 12 months by MSA
connector_secrets	Until disconnect + 24h	Until disconnect + 24h	Until disconnect + 24h	Until disconnect + 24h
account_data / workspace_config	Account life + 30 days	Account life + 30 days	Account life + 30 days	MSA may extend for legal hold
Encrypted backups	35-day rolling	35-day rolling	35-day rolling	35-day rolling, or customer-managed
support_data	24 months	24 months	24 months	24 months
Billing records (tax)	7 years	7 years	7 years	7 years
Infrastructure logs (non-audit)	90 days	90 days	90 days	90 days

Deletion

A workspace admin can delete a run — payload and metadata — from the dashboard. Deletion is queued immediately and applied to primary storage within 24 hours.

Backups are not scrubbed on demand. Copies inside an encrypted backup age out on the 35-day backup clock. We would rather write that sentence than imply an instant global erase we cannot perform.

On account closure you can export configuration and run history — JSON and CSV, plus the original files where we still hold them — for 30 days. Primary delete follows; backups have expired by day 65. A legal hold on Enterprise pauses deletion for named objects.

Data residency

Every tier runs in the same place: a Hetzner data center in Nuremberg, Germany. We do not offer another processing region.

05 — Encryption / 9 controls

Disk encryption is table stakes. Secrets get a second layer.

Encrypting a volume protects a stolen disk. It does nothing about a stolen application credential, which is the attack that actually happens.

In transit: TLS 1.2 minimum, TLS 1.3 preferred. HSTS on every host.
At rest, disks: [PLACEHOLDER: disk and backup encryption on the Hetzner server in Nuremberg — confirm at deployment]
At rest, application: Envelope encryption for connector secrets, bring-your-own-key material, and any API key you paste.
Key management: [PLACEHOLDER: where the master key lives on the Hetzner server — confirm at deployment]
Cipher suites: Mozilla Intermediate or stricter. No TLS 1.0 or 1.1, no RC4, no 3DES.
Secrets store: Runtime secrets are not in git and not in CI plaintext. [PLACEHOLDER: secrets tooling on the Hetzner server — confirm at deployment]
Key rotation: Automatic annual rotation of the master key, plus rotation on compromise. A new data key on every secret write.
Customer-managed keys: Planned for Enterprise, target 2027-06-30. Until then we manage the master key.
Certificates: Automated through Let's Encrypt. No long-lived uploaded certificates on customer-facing endpoints.

What the second layer is

Connector secrets get a per-record data key, envelope-wrapped by a master key, so a database dump is not a token dump. There is no plaintext API.

We do not use a customer-supplied HSM at launch, and we do not split keys with the customer at launch. Both are Enterprise conversations after customer-managed keys ship.

What we will not claim

Outbound email is TLS in transit where the recipient's mail server supports it. We cannot encrypt the body at rest inside the recipient's mailbox.
A connected write to QuickBooks or HubSpot is encrypted in transit to that vendor. Their at-rest story is theirs, and we do not restate it as ours.
Self-hosted encryption is yours. We document a recommended baseline in the licence runbook. We do not attest to your environment.

06 — Access control / 3 fixed roles

Seats are unlimited, so roles are the access control.

Charging for seats would make your security model a budget decision. It is not one here — nobody is left out of the workspace to save money, so permissions have to do the work.

Login on Starter: Email and password, Google OAuth, Microsoft OAuth.
SAML: SAML 2.0 on Growth and above. Identity-provider- and service-provider-initiated. SSO can be forced.
SCIM: SCIM 2.0 on Scale and above. Create, deactivate, and map groups to roles.
MFA: Required for password accounts. Identity-provider MFA is accepted for SSO accounts; we do not second-factor them.
Sessions: 7-day idle timeout, 30-day absolute, refresh token rotated.
IP allowlist: Growth and above.
Roles: Three fixed roles on Growth: owner, admin, member. Custom allow-list roles on Scale.
Staff access to payload: No standing access. Break-glass only: ticketed, MFA, capped at 4 hours, logged as an audit event.

The three roles on Growth

Fixed roles and what each one can do
Role	Can
owner	Billing, delete the workspace, transfer ownership, and everything an admin can do.
admin	Users, roles, SSO, IP allowlist, integrations, retention, all products, audit export.
member	Run and configure the products they are granted. Cannot connect a new OAuth app, cannot change retention, cannot see billing.

Scale custom roles are allow-lists, not deny-lists. The permissions that exist at launch are product run, product configure, integration connect, integration revoke, audit read, billing read, member invite, and settings write. No permission lets a member read another workspace.

Our own people

Background check before production access, in the US and where equivalent checks are lawful elsewhere.
Hardware-backed MFA (FIDO2 or equivalent) on our identity provider.
Production access is a separate reviewed group. It is not the default GitHub organisation role.
Break-glass access to a run payload requires a ticket, lasts at most 4 hours, and every query is logged as an audit event attributed to the staff user.
Staging is separate from production. Production data is not copied into it. Fixtures are synthetic.

07 — Audit logs

We log that a run happened and a hash of it. Not its contents.

Payload lives in its own store on its own clock. Mixing the two would mean your audit trail quietly became a second copy of every document.

What we log

Authentication including failures, MFA and SSO; role changes; invites; integration connect and revoke; retention changes; product activate and pause; run create and cancel; export of audit or run history; billing plan change; and staff break-glass.

How you get it out

CSV and JSON export from the dashboard on Growth and above. A SIEM stream over HTTPS on Scale and above.

Starter's 30-day audit window is not exportable to a SIEM; it is a filtered table in the UI. That is a stated limit and a reason to move up a plan, not a gap we hide.

08 — Model providers / 3 inference subprocessors

A model call happens only when the product needs one, and we name who receives it.

Posting a bill that already has a code, sending a template email, writing a CSV — none of those call a model. Extraction, classification, drafting and matching do.

What leaves the platform

When a call happens, what is sent is:

the minimum retrieved context the product needs — a vendor name, the line text, that vendor's codes from the last twelve months, not your whole company file;
the system instructions we wrote for that product.

Not sent: connector secrets, Stripe ids, any other tenant's data, data from products that do not use a model, or anything from a self-hosted deployment.

Retention and training at the provider

We execute zero-retention and no-training API terms with each model subprocessor where the endpoint offers them. If an endpoint cannot be put on no-training terms, we do not route customer data to it.

Zero retention at a provider is not the same as nobody can ever see this. Several providers keep a limited slice for abuse monitoring even under their zero-retention programme. We are not going to pretend that exception is absent.

nox.markets does not train on customer data, and does not use one customer's runs to improve another customer's products. Run counts, latency, credit burn and eval scores on our fixtures are how we operate the platform.

Platform subprocessors

These entities process customer personal data for all or most workspaces. Model providers are listed even though buyers below Scale never pick one. The same table, with its dated changelog, is on the trust center and in the legal subprocessor list.

Platform subprocessors that process customer personal data
Legal entity	Purpose	Data classes	Processing location	Contract	In production at launch
Hetzner Online GmbH	Server hosting, database, and backups	Account data, workspace config, connector secrets, run payload, run metadata, audit events, support data, website inquiries	Germany (Nuremberg)	Data processing agreement — to conclude before launch	Yes
Zoho Corporation B.V.	Email hosting for our mailboxes	Email you send us and our replies, including support requests	EU (Zoho EU data centers)	Data processing addendum — to request before launch	Yes
Stripe, Inc.	Payments, invoices, and tax on our own fees	Billing identity, card last four, subscription state. No card number on our side	US	Stripe DPA	No — checkout records a waitlist and takes no payment
OpenAI, LLC	Model inference	Prompt, retrieved context and completion, for products that call a model	US	DPA plus zero-retention or no-training terms where offered	No — no product in this build calls a model
Anthropic, PBC	Model inference	Prompt, retrieved context and completion, when routed there	US	DPA plus no-training or zero-retention terms where offered	No — no product in this build calls a model
Google LLC (Google Cloud / Vertex AI)	Model inference	Prompt, retrieved context and completion, when routed there	US	Google Cloud DPA	No — no product in this build calls a model

Conditional subprocessors

Used only when a workspace turns that feature on.

Conditional subprocessors, used only when their trigger applies
Legal entity	What turns it on	Data	Processing location
Slack Technologies, LLC	A Slack webhook is configured for new-inquiry alerts	Inquiry details: email, name, company, and the message	US
Google LLC	Sign in with Google is enabled	Name, email address, and Google account id	US
Plaid Inc.	The workspace connects a bank for a connected product that lists Plaid in its integrations	Account, balance and transaction data the product is configured to read	US

The systems we connect to on your behalf — QuickBooks Online, Xero, HubSpot, Gmail — are your processors, not our subprocessors. We hold a token; they already have the data. They appear on a product’s integration list, not in these tables. We give 30 days notice before a new entity processes customer personal data, and DPA customers have a 15-day window to object.

09 — Availability / 4 plans

Two plans have an availability SLA. Two do not, and we say which.

Starter and Growth are best effort with no service credits. Claiming otherwise would be a contract we do not intend to honour.

Full SLA and credits

Recovery objectives and availability SLA by plan
Plan	RPO — data we may lose	RTO — time to restore	Availability SLA
Starter	24 hours	8 hours, business hours	None. Best effort, no service credits
Growth	24 hours	8 hours, business hours	None. Support response SLA only
Scale	1 hour	4 hours	99.9% monthly
Enterprise	15 minutes	1 hour	99.95% monthly, with credits

Continuous write-ahead log shipping for the primary database, encrypted snapshots every 24 hours, 35-day retention, and no backup copies outside Germany. Restores are tested quarterly into an isolated environment; the first test is planned for 2026-12-31. [PLACEHOLDER: standby and failover for the single Hetzner server — confirm at deployment]

10 — Incident response / 6 steps

The clock starts when a human confirms it, not when a regulator asks.

A personal-data breach reaches the workspace owner within 72 hours of confirmation. A P1 availability incident reaches you within 24 hours of the declaration.

The clock

Detect — monitoring, a vendor notice, or a disclosure report.
Declare internally within 1 hour of a human confirming it is real, not a pager false positive.
Contain. Rotate credentials. Revoke tokens if a connector secret is in scope.
Confirm or rule out personal-data involvement. This is where the 72 hours starts. We do not start that clock on every CPU spike, and we do not sit on a likely breach for a week waiting to be sure — if it is likely, we notify as likely and update when it is confirmed.
Notify: who, what classes, what we know, what we do not know yet, and what we recommend you do. No speculation about root cause in the first notice.
Post-incident report to affected Scale and Enterprise customers within 10 business days of close.

What counts, and what does not

Counts: unauthorised access to a run payload, a connector secret, or account data; ransomware; a subprocessor breach that includes our tenants; an employee reading payload without a ticket.

Does not count: a user locking themselves out; a model hallucination, which is a product-quality incident we log and fix rather than a data breach; a customer exposing their own OAuth grant.

Availability incidents are posted to the status page. A security breach is never first announced on social media.

11 — Disclosure

EN ONLY

Report it privately and we will not send a lawyer after you.

Coordinated disclosure, acknowledged within three business days. There is no paid bounty programme yet, and we would rather say so than let you find out after the work.

Contact: security@nox.markets
security.txt: /.well-known/security.txt
Languages: English
Bounty: Not offered at launch. A paid programme is planned for 2027-06-30, after the first external penetration test.
Acknowledgement: Within 3 business days.
Safe harbour: Good-faith research that does not exfiltrate data beyond a proof of concept, does not degrade the service, and is reported privately first will not draw a legal threat from us.

Scope

In scope: production hosts under *.nox.markets, the API, authentication, tenant-isolation and IDOR issues, secret leakage, remote code execution, and stored cross-site scripting on app routes.

Out of scope: marketing-site issues with no authentication impact, SPF and DKIM nitpicks without a working spoof, automated scanner dumps with no proof of concept, social engineering of staff or customers, physical access, and denial of service.

Please do not: read another tenant's data beyond the one record that proves isolation is broken, run exploits against our staff, or ask us to decrypt a payload you exfiltrated. We will not pay a ransom.

12 — Vendor review / 15 questions

The fifteen questions that actually arrive on a vendor review.

Answers are short enough to paste into a SIG or CAIQ cell, and written so nothing has to be walked back on the follow-up call.

Question 01
Do you have SOC 2 Type II or ISO 27001 today?
No. SOC 2 Type I is planned for 2027-05-31. SOC 2 Type II is planned for 2027-12-15, after a six-month observation window. ISO 27001 is planned for 2028-09-30. CCPA/CPRA compliance is an operational legal programme, not a certification. Current status always lives on the trust page. We will not send a SOC 2 in progress letter that implies a report exists.
Question 02
Where is data stored, and are you multi-tenant?
A Hetzner data center in Nuremberg, Germany, on every tier; no other processing region is offered. Logical isolation on shared infrastructure, with a dedicated VPC or self-hosted on Enterprise. Every row carries a tenant id, and cross-tenant tests are part of release QA.
Question 03
Is customer data used to train models?
No. Not by nox.markets, and not by the model subprocessors we route to, under the API terms we will actually sign. This is in the DPA, not only on the website.
Question 04
What data do you send to OpenAI, Anthropic or Google, and do they keep it?
For products that use a model: the prompt, the retrieved context and the completion. Not OAuth tokens, not other tenants, not full system exports. We use no-training or zero-retention endpoints where they are offered. Providers may retain a limited slice for abuse monitoring even under zero retention, and we do not hide that. Below Scale we choose the vendor; the subprocessor list still names them.
Question 05
Encryption at rest and in transit? Who holds the keys?
TLS 1.2 minimum and TLS 1.3 preferred in transit. AES-256 at rest. [PLACEHOLDER: key management on the Hetzner server — confirm at deployment] Application-level envelope encryption for connector secrets. We hold the customer master key at launch. Customer-managed keys are planned for Enterprise on 2027-06-30.
Question 06
SSO, SAML, SCIM?
Google and Microsoft OAuth on Starter. SAML 2.0 on Growth and above. SCIM 2.0 on Scale and above. SSO can be forced. SCIM deprovisioning revokes sessions within 5 minutes.
Question 07
What are the roles, and can your staff read our documents?
Three roles on Growth: owner, admin, member. Custom roles on Scale. Our staff have no standing access to run payloads. Break-glass access is ticketed, capped at 4 hours, requires MFA, and is logged. An Enterprise MSA can require that we notify you when payload is accessed.
Question 08
Audit logs: what, how long, can we stream them to a SIEM?
Authentication, role changes, integration connect and revoke, runs as metadata plus a payload hash rather than a body, exports, and staff break-glass. Retention is 30 days on Starter, 12 months on Growth, 36 months on Scale and Enterprise. SIEM streaming is available on Scale and above.
Question 09
Backups, RPO, RTO?
Encrypted snapshots daily, continuous write-ahead log shipping, 35-day retention, stored in Germany. RPO and RTO are 24 hours and 8 hours on Starter and Growth, 1 hour and 4 hours on Scale, 15 minutes and 1 hour on Enterprise. Restores are tested quarterly; the first test is planned for 2026-12-31.
Question 10
Independent penetration test?
Annual, web and API, starting with a first test planned for 2026-12-15. A letter of attestation can be public; the full report is under NDA on Scale and above. We do not publish a pentest PDF on a marketing page.
Question 11
Vulnerability management and patching SLAs?
Critical, meaning actively exploited or CVSS 9 and above and reachable: 24 hours. High: 7 days. Medium: 30 days. Low: 90 days. Dependencies are scanned in CI, and containers for application services are rebuilt rather than patched in place.
Question 12
Subprocessors, and how do we hear about changes?
The list is public and is the same table on this page and in the legal subprocessor page. We give 30 days notice before a new entity processes customer personal data, with a 15-day objection window for DPA customers. The SaaS tools we OAuth into on your behalf are your processors, not our subprocessors.
Question 13
What happens to data when we cancel?
A 30-day export window for configuration and run history in open formats. Primary deletion by day 30; backups are gone by day 65. Connected OAuth grants are revoked, and work already written to your general ledger or CRM stays there. Self-hosted data is on your disk. A purchased one-time licence survives churn, but the data still follows this clock.
Question 14
Incident notification timeline?
A personal-data breach is notified to the workspace owner no later than 72 hours after we confirm it. A P1 availability incident is notified within 24 hours and appears on the status page. We do not delay customer notice until a press release exists.
Question 15
Background checks, MFA, and production access for your employees?
Background checks before production access where lawful. Hardware-backed MFA on our identity provider. Production and staging are separate, and production data is not copied to staging. Production access is a reviewed group, not everyone in engineering.

13 — Documents / 6 documents

The paper behind the page.

Every control above is incorporated by reference into the DPA. These are drafts prepared for counsel review, and each one says so at the top.

Next step

Send the questionnaire. We answer it in writing.

Ask for the DPA, the subprocessor list, or the answers to a spreadsheet you have already been handed. If your MSA needs a person on a call, book one.