The CAIQ, answered
A security questionnaire a vendor review can take as it is: every control of the Cloud Controls Matrix v4, with a plain Yes, No or not applicable, why, and where to check.
What this is
The Cloud Security Alliance's Consensus Assessments Initiative Questionnaire (CAIQ) v4 asks its questions under the 197 controls of its Cloud Controls Matrix v4. Every one of those controls is answered below, Yes, No or not applicable, with a short reason and the page or file to check it on.
- It is our own answer, not an audit. Nobody independent has checked it, it is not a CSA STAR entry, and the site holds no SOC 2 report or ISO 27001 certificate. Where something is not in place, the answer is No.
- The control names are in our words. The CAIQ's question text is the CSA's. Match each row to your copy by its control ID; where your copy asks several questions under one control, the answer here covers them all, and the note says where it does not.
- Not applicable means the thing does not exist here, not that we chose to skip it: there are no data centres of our own, and no staff besides the owner.
It is generated, with the CSV, from one file, and the build stops if a control is unanswered, an answer is not Yes, No or NA, or a piece of evidence points at a page that does not exist.
Who is responsible for what
Several answers turn on this, so here it is in one place.
| What | Whose it is |
|---|---|
| Your files, and what you type into the tools | Yours. They stay on your device; this site never receives them. |
| Your devices, browsers and backups | Yours. |
| Your key, and who in your organisation has a seat | Yours. Your admin gives seats and takes them back. |
| The site's code, what it is allowed to do, and the records the server keeps | Ours: the owner, who runs OBSCURA OS alone and holds every role. |
| The hosting, the network, the store and its encryption at rest | Cloudflare's. |
| Payments and the card data behind them | Stripe's. |
| Sending email, once it is switched on | Resend's. |
Each company and what it receives is on the sub-processor list.
The answers
Answered on 1 October 2026: 197 controls, 53 Yes, 112 No and 32 not applicable. The same answers are in the CSV.
A&A: Audit and assurance
| Control | Answer | Why, and where to check |
|---|---|---|
| A&A-01 Audit and assurance policy and procedures | No | There is no written audit and assurance policy. What the site does is published, and the build checks the published account against the code. trust |
| A&A-02 Independent assessments | No | Nobody independent has audited, assessed or penetration-tested the service. security#what-is-not-in-place |
| A&A-03 Risk-based planning of assessments | No | There is no assessment programme to plan. security#what-is-not-in-place |
| A&A-04 Compliance with requirements | No | Compliance with laws, standards and contracts is not verified by any formal process. The commitments are in the data processing agreement; nobody independent checks them. dpa |
| A&A-05 Audit management process | No | No audits are carried out, so there is no process for managing them. security#what-is-not-in-place |
| A&A-06 Remediation of audit findings | No | There are no audit findings and no remediation process for them. Reported security problems are handled as the security page says. security |
AIS: Application and interface security
| Control | Answer | Why, and where to check |
|---|---|---|
| AIS-01 Application and interface security policy and procedures | No | There is no written policy. The practice is published: what is and is not in place, and the threat model tool by tool. security, threat-model |
| AIS-02 Application security baseline | Yes | Every page is sent the same enforcing Content-Security-Policy, HSTS, nosniff, frame-ancestors and Permissions-Policy from one file, quoted word for word on /trust by the build, and checked on every change. trust#policy |
| AIS-03 Application security metrics | No | No security metrics are defined or tracked. security#what-is-not-in-place |
| AIS-04 Secure design and development lifecycle | No | There is no formal development lifecycle. The design keeps documents in the browser and off the server, and every change runs the automated checks, but no lifecycle is written down or assessed. trust, threat-model |
| AIS-05 Automated application security testing | Yes | Automated checks run on every push and pull request: the headers and policy, no off-site loads, the Pro lock refusing a request without a key, CSV cells a spreadsheet would run, licence signing, and the facts on /trust against the code. They report within minutes; they do not hold back a deploy. trust |
| AIS-06 Automated secure deployment | Yes | Cloudflare Pages builds each push to the main branch from the repository; nobody uploads files by hand. Each deploy's files and their SHA-256 are published. releases.json, trust#releases |
| AIS-07 Application vulnerability remediation | Yes | Reports go to Security@ObscuraOS.com and are acknowledged within three business days (a target, not a guarantee); a fix ships by the same deploy path as any change. There is no paid bounty. security, .well-known/security.txt |
BCR: Business continuity and operational resilience
| Control | Answer | Why, and where to check |
|---|---|---|
| BCR-01 Business continuity management policy and procedures | No | There is no business continuity management policy. A continuity statement is published, saying what a customer keeps if the service stops. continuity |
| BCR-02 Risk assessment and business impact analysis | No | No business impact analysis has been done. continuity |
| BCR-03 Business continuity strategy | No | No formal strategy. The design is the strategy there is: customers' work stays on their own devices in documented formats. continuity#the-formats |
| BCR-04 Business continuity planning | No | There is no business continuity plan. continuity#what-is-not-offered |
| BCR-05 Continuity documentation | No | What there is is public (the continuity statement, the incident response policy and the status record), but it is not reviewed on a schedule. continuity, incident-response, status |
| BCR-06 Business continuity exercises | No | No exercises are run. continuity#what-is-not-offered |
| BCR-07 Communication with stakeholders | Yes | The owner posts notes about incidents on the status page, and customers are emailed as the incident response policy says. status, incident-response#how-you-are-told |
| BCR-08 Backup | No | There is no separate backup of the server's records beyond what Cloudflare keeps. Customers' work is on their own devices; a Team or Business admin can download the record of seat changes at any time. continuity#what-is-not-offered, seats |
| BCR-09 Disaster response plan | No | There is no written disaster response plan. continuity#what-is-not-offered |
| BCR-10 Response plan exercise | No | No plan, so no exercise of one. continuity#what-is-not-offered |
| BCR-11 Equipment redundancy | NA | No equipment of our own: the site runs on Cloudflare's network, whose redundancy is Cloudflare's. subprocessors |
CCC: Change control and configuration
| Control | Answer | Why, and where to check |
|---|---|---|
| CCC-01 Change management policy and procedures | No | There is no written change management policy. Every change is a commit in the repository and runs the automated checks. trust |
| CCC-02 Quality testing and approval of changes | No | Changes are tested automatically on every push, but there is no approval step: one person makes and releases them, and the checks do not hold back a deploy. trust |
| CCC-03 Change management technology | Yes | Every change is a git commit that can be reverted, and Cloudflare Pages keeps each deployment, so an earlier one can be put back. releases.json |
| CCC-04 Protection against unauthorised change | Yes | Only the owner's GitHub and Cloudflare accounts can change what is deployed. Each deploy's file list and hashes are published, so a change nobody announced can be found. trust#releases |
| CCC-05 Change agreements with customers | No | Customers are not asked before a change is released. Changes are listed on What's new. whats-new |
| CCC-06 Change management baseline | Yes | The main branch of the repository is the baseline; the site is built from it, and the release list records what each build holds. releases.json |
| CCC-07 Detection of deviation from the baseline | Yes | The build stops when a generated page or the facts on /trust differ from the code; every committed library is held to its pinned SHA-256; and the published release list lets anybody compare what they were served with the build. trust#releases, sbom.json |
| CCC-08 Exception management | No | There is no exception process. caiq#ssrm |
| CCC-09 Change restoration | Yes | A change is undone by reverting its commit, or by putting back an earlier Cloudflare Pages deployment. releases.json |
CEK: Cryptography, encryption and key management
| Control | Answer | Why, and where to check |
|---|---|---|
| CEK-01 Encryption and key management policy and procedures | No | There is no written encryption and key management policy. security |
| CEK-02 Cryptography roles and responsibilities | No | No roles are defined. The owner holds every key. caiq#ssrm |
| CEK-03 Data encryption | Yes | HTTPS everywhere with HSTS for a year including subdomains. Cloudflare encrypts what Workers KV holds at rest; we hold no separate keys for it. security#what-is-in-place, dpa |
| CEK-04 Encryption algorithms | Yes | Keys are signed with Ed25519 and hashed with SHA-256; TLS is Cloudflare's. Where the tools encrypt, they use AES-256-GCM with keys made by PBKDF2-SHA256 at 310,000 iterations, or age. security, continuity#format-sovereign |
| CEK-05 Encryption change management | No | There is no process for changing cryptography. security |
| CEK-06 Cost-benefit analysis of encryption changes | No | No such analysis is done. security |
| CEK-07 Encryption risk management | No | There is no encryption risk programme. security |
| CEK-08 Customer-managed keys | No | The few records the service keeps are encrypted at rest under Cloudflare's keys, which a customer cannot manage. What the tools encrypt on the customer's device is under keys only the customer holds, and never reaches us. dpa, trust#map |
| CEK-09 Encryption and key management audit | No | Not audited. security#what-is-not-in-place |
| CEK-10 Key generation | Yes | Signing and verification use the platform's own Web Crypto (Ed25519), and invitation tokens are 32 random bytes from the platform's secure random source. security#business-and-team-seats |
| CEK-11 Key purpose | Yes | Each secret has one job: the licence signing key signs keys, the Stripe key reads Stripe, the Resend key sends email, the webhook secret checks Stripe's events, and the owner's keys open /stats and the waitlist export. trust#map |
| CEK-12 Key rotation | No | There is no rotation schedule; a key is replaced when there is a reason to. incident-response#what-happens |
| CEK-13 Key revocation | Yes | Any secret can be replaced in Cloudflare at once, and the incident response policy says to replace whatever leaked first. A Team or Business admin key can be replaced, after which every earlier copy is refused. incident-response#what-happens, security#business-and-team-seats |
| CEK-14 Key destruction | No | There is no defined process for destroying keys. security |
| CEK-15 Key activation | No | There is no defined process for activating keys. security |
| CEK-16 Key suspension | No | There is no defined process for suspending keys. security |
| CEK-17 Key deactivation | No | There is no defined process for deactivating keys at the end of their life. security |
| CEK-18 Key archival | No | Keys are not archived. security |
| CEK-19 Use of compromised keys | No | There is no defined process; a compromised key is replaced. incident-response#what-happens |
| CEK-20 Key recovery | No | There is no key recovery process. security |
| CEK-21 Key inventory | No | There is no maintained inventory of keys with their life cycle. security |
DCS: Data centre security
| Control | Answer | Why, and where to check |
|---|---|---|
| DCS-01 Off-site equipment disposal | NA | We operate no data centre, equipment or media. Hosting is Cloudflare's, and so is this control. subprocessors |
| DCS-02 Off-site transfer authorisation | NA | No equipment of our own to move. Hosting is Cloudflare's. subprocessors |
| DCS-03 Secure areas | NA | No premises holding customer data. Hosting is Cloudflare's. subprocessors |
| DCS-04 Secure transport of media | NA | No physical media holding customer data. subprocessors |
| DCS-05 Classification of assets | No | Assets are not classified by business risk. sbom.json |
| DCS-06 Cataloguing and tracking assets | No | There is no asset register. What exists in its place: every third-party library is listed in the SBOM, and every file of each build in the release list. sbom.json, releases.json |
| DCS-07 Controlled access points | NA | No premises of our own. Hosting is Cloudflare's. subprocessors |
| DCS-08 Equipment identification | NA | No equipment of our own. Hosting is Cloudflare's. subprocessors |
| DCS-09 Secure area authorisation | NA | No secure areas of our own. Hosting is Cloudflare's. subprocessors |
| DCS-10 Surveillance | NA | No premises of our own. Hosting is Cloudflare's. subprocessors |
| DCS-11 Response to unauthorised physical access | NA | No premises of our own. Hosting is Cloudflare's. subprocessors |
| DCS-12 Cabling security | NA | No cabling of our own. Hosting is Cloudflare's. subprocessors |
| DCS-13 Environmental systems | NA | No data centre of our own. Hosting is Cloudflare's. subprocessors |
| DCS-14 Secure utilities | NA | No data centre of our own. Hosting is Cloudflare's. subprocessors |
| DCS-15 Equipment location | NA | No equipment of our own. Hosting is Cloudflare's. subprocessors |
DSP: Data security and privacy
| Control | Answer | Why, and where to check |
|---|---|---|
| DSP-01 Security and privacy policy and procedures | Yes | The privacy policy and the data processing agreement say what is held, why, for how long and who else handles it. privacy, dpa |
| DSP-02 Secure disposal | Yes | Records expire by themselves: an invitation after fourteen days, a removed seat after 400 days. After a subscription ends, its records are deleted within thirty days of a request. Disposal of the storage underneath is Cloudflare's. dpa, trust#map |
| DSP-03 Data inventory | Yes | Every kind of record the server keeps is listed on /trust, found by the build from the prefixes the code writes, with what it holds and how long. trust#map |
| DSP-04 Data classification | No | There is no formal classification scheme. trust#map |
| DSP-05 Data flow documentation | Yes | Every server route with what arrives and what is kept, and every outside address the code contacts, are on /trust and the sub-processor list, checked against the code by the build. trust#map, subprocessors |
| DSP-06 Data ownership and stewardship | Yes | For seat data the customer is the controller and we are its processor; the data processing agreement says so and what follows from it. dpa |
| DSP-07 Data protection by design and default | Yes | The tools run in the browser on files from the person's own device, and the policy every page is sent with lets a page send requests only to this site, so documents are not uploaded by design. trust#check, verify |
| DSP-08 Privacy by design and default | Yes | The page count stores daily totals with no address, browser, cookie or identifier, and sends nothing when Global Privacy Control or Do Not Track is on. There are no accounts and no advertising. privacy, trust#map |
| DSP-09 Data protection impact assessment | No | No DPIA has been carried out. dpa |
| DSP-10 Transfer of sensitive data | Yes | Personal data travels only over HTTPS and only to the sub-processors listed, each under its own data processing terms. subprocessors |
| DSP-11 Data subject rights | Yes | A customer's admin sees and can remove everything held about a person; requests made to us directly are passed to the customer and helped with. Anybody on the waitlist can unsubscribe. dpa, unsubscribe |
| DSP-12 Limitation of purpose | Yes | Seat data is used only to provide the seats: not for marketing, not sold. dpa |
| DSP-13 Sub-processing of personal data | Yes | Sub-processors work under their own data processing terms, including the safeguards for transfers between countries where those apply. dpa, subprocessors |
| DSP-14 Disclosure of sub-processors | Yes | The sub-processors are listed with what each receives, where and since when, and customers are emailed thirty days before one is added or replaced. subprocessors |
| DSP-15 Production data in non-production environments | Yes | The checks run on made-up data with stand-ins for Stripe and the store; production records are not copied anywhere for testing. trust |
| DSP-16 Data retention and deletion | Yes | How long each record is kept is stated for each kind, and most expire by themselves. trust#map, dpa |
| DSP-17 Protection of sensitive data | Yes | Little is held, and that little is limited: invitations stored only as a hash, the Pro key cookie sent to /pro-code/ alone, a sign-in address kept only as a hash for a day. trust#map, security#business-and-team-seats |
| DSP-18 Requests for disclosure from authorities | No | No procedure for requests from law enforcement or other authorities is written down or published. dpa |
| DSP-19 Data location | No | No region is chosen for the store; Cloudflare decides where copies are kept, and the sub-processors may hold data in any country they operate in. subprocessors, dpa |
GRC: Governance, risk and compliance
| Control | Answer | Why, and where to check |
|---|---|---|
| GRC-01 Governance programme policy and procedures | No | There is no governance programme. security |
| GRC-02 Risk management programme | No | There is no risk management programme. security |
| GRC-03 Review of policies | No | Policies are not reviewed on a schedule. security |
| GRC-04 Policy exception process | No | There is no exception process. security |
| GRC-05 Information security programme | No | There is no information security programme; the security page says what is in place and what is not. security |
| GRC-06 Governance responsibility model | Yes | One person, the owner, is responsible for all of it, as the security page and the incident response policy say; who is responsible for what between us and the customer is set out on this page. caiq#ssrm, incident-response#what-happens |
| GRC-07 Regulatory mapping | No | Requirements are not mapped to the systems formally. dpa |
| GRC-08 Special interest groups | No | No membership of security interest groups. security |
HRS: Human resources
| Control | Answer | Why, and where to check |
|---|---|---|
| HRS-01 Background screening | NA | No staff: the owner runs the site alone, so there is nobody to screen. security |
| HRS-02 Acceptable use of technology by staff | NA | No staff. (The acceptable use policy for customers is published.) acceptable-use |
| HRS-03 Clean desk | NA | No staff and no office holding customer data. security |
| HRS-04 Remote and home working | NA | No staff. security |
| HRS-05 Return of assets | NA | No staff, so no assets to return. security |
| HRS-06 End of employment | NA | No staff. security |
| HRS-07 Employment agreements process | NA | No staff. security |
| HRS-08 Employment agreement content | NA | No staff. security |
| HRS-09 Personnel roles and responsibilities | NA | No staff besides the owner, who holds every role. caiq#ssrm |
| HRS-10 Non-disclosure agreements | NA | No staff. security |
| HRS-11 Security awareness training | NA | No staff, so no training programme. security |
| HRS-12 Personal and sensitive data training | NA | No staff, so no training programme. security |
| HRS-13 Staff compliance responsibility | NA | No staff. security |
IAM: Identity and access management
| Control | Answer | Why, and where to check |
|---|---|---|
| IAM-01 Identity and access management policy and procedures | No | There is no written policy. How access works is published: signed keys, no accounts, seats given and taken back by the customer's admin. security#business-and-team-seats |
| IAM-02 Strong password policy | No | The service has no passwords: customers hold signed keys. The owner's own accounts at GitHub, Cloudflare and Stripe are not covered by a written policy. security |
| IAM-03 Identity inventory | Yes | A Team or Business admin sees every seat, who holds it, when it was added and when its key last renewed, and can download the record of every change. seats, dpa |
| IAM-04 Separation of duties | No | One person does everything, so duties are not separated. caiq#ssrm |
| IAM-05 Least privilege | Yes | Each secret can do one job, the Stripe key is a restricted key, the Pro key cookie is sent only to /pro-code/, and replies from /api/ carry a policy of default-src 'none'. trust#policy, trust#map |
| IAM-06 User access provisioning | Yes | A seat is added by the customer's admin and taken by its holder with a one-time link that runs out after fourteen days. security#business-and-team-seats |
| IAM-07 Changing and removing access | Yes | A seat removed by the admin is refused by the server within about two minutes wherever its holder is online; a device kept offline keeps working until its key runs out, 35 days at most. security#business-and-team-seats, trust#pro |
| IAM-08 Review of user access | No | We do not review access on a schedule. A customer's admin can review its own seats at any time. seats |
| IAM-09 Segregation of privileged roles | No | One person holds every privileged role. caiq#ssrm |
| IAM-10 Management of privileged roles | No | There is no process for granting or reviewing privileged access; only the owner has it. caiq#ssrm |
| IAM-11 Customer approval of privileged access | No | Customers are not asked to approve the owner's access to the store that holds their seat records. dpa |
| IAM-12 Integrity of logs | No | The record of seat changes is never rewritten by the code, but the owner's account could change it; nothing makes it tamper-evident. trust#map |
| IAM-13 Uniquely identifiable users | Yes | Every seat has a key of its own, and every change in the seat record names the fingerprint of the admin key that made it. security#business-and-team-seats |
| IAM-14 Strong authentication | No | Customers are authenticated by Ed25519-signed keys that the server checks with Stripe, but whether the owner's own accounts use multi-factor authentication is not published, so this cannot be answered Yes here. Ask, and we will answer for your review. security |
| IAM-15 Password management | NA | No passwords in the service: a key is a signed statement, not a secret a person types. security |
| IAM-16 Authorisation mechanisms | Yes | Before any paid code is served, the server checks the key's signature, plan, date and generation, and that Stripe says the subscription is paid. trust#pro |
IPY: Interoperability and portability
| Control | Answer | Why, and where to check |
|---|---|---|
| IPY-01 Interoperability and portability policy and procedures | No | There is no written policy. In practice everything saves in standard formats, and the paid applications' own formats are documented. formats, continuity#the-formats |
| IPY-02 Programmatic access to data | No | There is no API for customers. Their work is in files on their own devices, and the record of seat changes downloads as CSV. seats, continuity |
| IPY-03 Secure interoperability and portability | Yes | Everything travels over HTTPS, and data leaves in standard, documented formats. continuity#the-formats |
| IPY-04 Data portability in the contract | Yes | The data processing agreement says the record can be downloaded at any time, and how long records are kept and deleted after the subscription ends. dpa |
IVS: Infrastructure and virtualisation security
| Control | Answer | Why, and where to check |
|---|---|---|
| IVS-01 Infrastructure and virtualisation security policy and procedures | No | There is no written policy. The infrastructure is Cloudflare's, and what runs on it is listed on /trust. trust |
| IVS-02 Capacity and resource planning | No | There is no capacity plan; the site runs within Cloudflare's limits. subprocessors |
| IVS-03 Network security | Yes | HTTPS everywhere; a page may send requests only to this site; and every route under /api/ refuses a write from another website, caps the size of what is sent and limits how often one address can write. trust#policy, trust#map |
| IVS-04 Operating system hardening | NA | No operating systems of our own: the code runs on Cloudflare's platform. subprocessors |
| IVS-05 Separation of production and non-production | Yes | Tests run on a local server and in GitHub Actions with stand-ins for Stripe and the store; the production secrets and records exist only in the Cloudflare project. trust |
| IVS-06 Segmentation between customers | Yes | Each plan's seats are held under its own subscription, and a request sees only the seats of the subscription its key belongs to; anything else gets a 404. security#business-and-team-seats |
| IVS-07 Migration to cloud environments | NA | Nothing is migrated: the service was built on Cloudflare. subprocessors |
| IVS-08 Network architecture documentation | Yes | Every route, every record and every outside address is documented on /trust, from the code, by the build. trust#map |
| IVS-09 Network defence | Yes | Cloudflare's network sits in front of every request; the server's own routes add rate limits and size caps. trust#map, subprocessors |
LOG: Logging and monitoring
| Control | Answer | Why, and where to check |
|---|---|---|
| LOG-01 Logging and monitoring policy and procedures | No | There is no written logging policy. trust#map |
| LOG-02 Retention and protection of audit logs | No | The server keeps no audit log of its own beyond the record of seat changes. trust#map |
| LOG-03 Security monitoring and alerting | No | There is no security monitoring. The one automated check, every thirty minutes once switched on, asks whether the Pro lock still refuses a request without a key, and GitHub reports a failure. status |
| LOG-04 Access to audit logs | No | No audit logs of our own to control access to. trust#map |
| LOG-05 Monitoring of and response to audit logs | No | No logs are monitored. trust#map |
| LOG-06 Clock synchronisation | NA | No servers of our own: times come from Cloudflare's platform. subprocessors |
| LOG-07 Logging scope | No | What is logged is not defined beyond the seat record. trust#map |
| LOG-08 Audit records | Yes | For seats: every change is recorded with what it was, when, the person, and the fingerprint of the admin key that made it, and the admin can download it. dpa, seats |
| LOG-09 Protection of log records | No | The seat record is kept and never rewritten by the code, but nothing stops the owner's account changing it. trust#map |
| LOG-10 Monitoring and reporting of encryption | No | Not monitored. security |
| LOG-11 Logging of key life-cycle events | No | Key life-cycle events are not logged. security |
| LOG-12 Physical access logs | NA | No premises of our own. subprocessors |
| LOG-13 Reporting failures of monitoring | No | Nothing notifies anybody when the scheduled check stops; the status page does say, to whoever opens it, that its record is out of date. status |
SEF: Security incidents, e-discovery and forensics
| Control | Answer | Why, and where to check |
|---|---|---|
| SEF-01 Security incident management policy and procedures | Yes | The incident response and breach notification policy is published. incident-response |
| SEF-02 Timely management of incidents | Yes | The same policy says what is done first and within what time people are told. incident-response#who-is-told-and-when |
| SEF-03 Incident response plan | Yes | The steps are written: stop it, find out what it touched, tell people, fix it and write it down. incident-response#what-happens |
| SEF-04 Testing of incident response | No | The plan has not been tested by a drill. incident-response#reporting-one |
| SEF-05 Incident response metrics | No | No metrics are kept. incident-response |
| SEF-06 Triage of events | No | There is no triage process beyond the plan's steps. incident-response#what-happens |
| SEF-07 Security breach notification | Yes | Customers are told without undue delay after we become aware, as the data processing agreement promises; the authority within 72 hours where the GDPR or UK GDPR requires it; the people affected without undue delay where they are at high risk. incident-response#who-is-told-and-when, dpa |
| SEF-08 Points of contact with authorities | No | No list of contacts at authorities is maintained. incident-response |
STA: Supply chain, transparency and accountability
| Control | Answer | Why, and where to check |
|---|---|---|
| STA-01 Shared responsibility model policy and procedures | No | There is no written policy for applying a shared responsibility model; the model itself is set out on this page. caiq#ssrm |
| STA-02 Shared responsibility through the supply chain | No | Not applied formally to the supply chain. subprocessors |
| STA-03 Shared responsibility guidance for customers | Yes | Who is responsible for what, between this site, its sub-processors and the customer, is set out on this page. caiq#ssrm |
| STA-04 Ownership of controls | Yes | The same table says who owns each part: the code and the records it keeps are ours, hosting is Cloudflare's, payment data is Stripe's, files, devices and keys are the customer's. caiq#ssrm |
| STA-05 Review of providers' responsibility documentation | No | The providers' own shared responsibility documents are not reviewed formally. subprocessors |
| STA-06 Implementing our part of the model | No | Our part is not audited or assessed. security#what-is-not-in-place |
| STA-07 Supply chain inventory | Yes | Every company the service uses is on the sub-processor list, and every third-party library the site ships is in the SBOM. subprocessors, sbom.json |
| STA-08 Supply chain risk management | No | Suppliers' risks are not reviewed on a schedule. subprocessors |
| STA-09 Service agreements | Yes | The terms and the data processing agreement are published: the scope, what is processed, how it is kept safe, breach notification, how questions about compliance are answered, and what happens at the end. terms, dpa |
| STA-10 Review of supply chain agreements | No | Agreements with suppliers are not reviewed on a schedule. subprocessors |
| STA-11 Internal compliance testing | No | There is no internal compliance testing beyond the automated checks. trust |
| STA-12 Suppliers' compliance with security requirements | No | There is no policy requiring it; the sub-processors work under their own terms. subprocessors |
| STA-13 Supply chain governance review | No | Not reviewed. subprocessors |
| STA-14 Supply chain data security assessment | No | Suppliers' data security is not assessed. subprocessors |
TVM: Threat and vulnerability management
| Control | Answer | Why, and where to check |
|---|---|---|
| TVM-01 Threat and vulnerability management policy and procedures | No | There is no written policy. security |
| TVM-02 Malware protection policy and procedures | No | There is no written policy. security |
| TVM-03 Vulnerability remediation schedule | No | There is no schedule; problems are fixed as they are found. Reporters are asked to allow ninety days before publishing. security |
| TVM-04 Updating detection tools | No | No detection tools are run. security |
| TVM-05 Vulnerabilities in external libraries | No | Every library is pinned to a version and a SHA-256 and listed in the SBOM, so it can be checked, but nothing scans them for vulnerabilities automatically. sbom.json |
| TVM-06 Penetration testing | No | No penetration test has been carried out. security#what-is-not-in-place |
| TVM-07 Vulnerability identification | No | Vulnerabilities are not looked for on a schedule. security |
| TVM-08 Vulnerability prioritisation | No | There is no defined way of prioritising. security |
| TVM-09 Vulnerability management reporting | No | There is no reporting to stakeholders; reporters are credited on the security page if they wish. security |
| TVM-10 Vulnerability management metrics | No | No metrics are kept. security |
UEM: Universal endpoint management
| Control | Answer | Why, and where to check |
|---|---|---|
| UEM-01 Endpoint devices policy and procedures | No | There is no endpoint policy: the owner's own devices are used, with no written standard. security |
| UEM-02 Approved applications and services | No | There is no approved list. security |
| UEM-03 Compatibility of endpoints | No | There is no defined list of compatible systems for the owner's devices. security |
| UEM-04 Endpoint inventory | No | No inventory is kept. security |
| UEM-05 Endpoint management | No | Nothing is enforced centrally. security |
| UEM-06 Automatic screen lock | No | Not enforced centrally. security |
| UEM-07 Operating system updates | No | Not managed centrally. security |
| UEM-08 Storage encryption | No | Not enforced centrally. security |
| UEM-09 Anti-malware | No | Not enforced centrally. security |
| UEM-10 Software firewall | No | Not enforced centrally. security |
| UEM-11 Data loss prevention | No | No data loss prevention on endpoints. security |
| UEM-12 Remote locate | No | Not managed centrally. security |
| UEM-13 Remote wipe | No | Not managed centrally. security |
| UEM-14 Security of third-party endpoints | No | There is no process for third parties' devices. security |