Security questionnaire

Answers to the questions vendor-security reviews usually ask (in the style of SIG Lite and CAIQ Lite). Each answer says what is true today; "Not yet" means exactly that. The security overview has the detail. For anything not covered here, write to huanting.w@nice2.io.

Company and governance

#	Question	Answer
1	Who provides the service?	NICETO LTD, 71-75 Shelton Street, Covent Garden, London, United Kingdom, WC2H 9JQ.
2	Who is responsible for security?	A named security owner at NICETO LTD; contact huanting.w@nice2.io.
3	Do you have written security policies?	Not yet as a formal policy set. Our controls are described in the security overview and our operations runbook (deployment, rollback, backups and restore, secret rotation, alert handling).
4	Are you SOC 2 or ISO 27001 certified?	Not yet. The service runs on Google Cloud, and the sandboxes of a project set to Azure on Microsoft Azure; both hold SOC 2 and ISO 27001 certifications for their infrastructure.
5	Has an independent penetration test been done?	Not yet. An external penetration test is planned before our first enterprise contract.
6	Are you registered with the UK Information Commissioner's Office (ICO)?	Registration (the data protection fee) is on our launch checklist and not yet complete.
7	Do you have a Data Processing Agreement?	Yes, as a draft pending legal review: see the DPA. Enterprise plans include a signed DPA.

Access control

#	Question	Answer
8	How do your users sign in?	With GitHub or Google, by a sign-in link sent to their email (once, within 15 minutes), or by a one-time invitation link (valid 14 days). GitHub and Google sign-in uses OAuth 2.0 / OpenID Connect with PKCE; only an email address the provider has verified matches an account, and the provider's tokens are not stored. After sign-in they hold a session cookie (HttpOnly, SameSite=Lax, Secure), which ends after 7 days without use and after 30 days at most. The CLI signs in with a device code approved in the browser. There are no passwords. Joining asks for the Terms of Service and the Acceptable Use Policy. Until a person has accepted the version in force, the platform refuses their sessions and CLI tokens everything but accepting them and signing out. Self-service sign-up, by email or with GitHub or Google, can be switched on. While it is off, only people invited to an organization get in.
9	Do you support SSO (SAML / OIDC) or SCIM?	Not yet.
10	Are there roles within a customer organization?	Yes: members and owners. Only owners can change organization policy (limits and retention), the organization's name and language, and its members: invite, remove, or change a member's role (an organization always keeps at least one owner). Removing a member revokes the test runners they paired, the project API tokens and CLI tokens they made, their developer-machine connections and their sessions. The automatic runs they switched on stop and the owners are told. The runs stay stopped until someone in the organization takes them over. A run they started that ends after they left is mailed to the owners, not to them.
11	Can automated clients make sensitive changes?	No. Confirming tests, setting pass criteria, starting tests, pairing test runners, storing secrets, binding repositories and changing policy need a signed-in person in the browser. CLI tokens and the in-app assistant cannot do them.
12	How are customers kept apart?	Every query is filtered by organization, and another organization's resources answer "not found". Every cloud run gets its own virtual machine, which is deleted afterwards.
13	How is administrative access to production controlled?	Through Google Cloud IAM, and for the Azure subscription that holds sandbox virtual machines, Microsoft Entra ID and Azure role-based access control. SSH to the control plane goes only through Google's Identity-Aware Proxy with OS Login (port 22 is closed to the internet). The database has a private IP address only.
14	Is multi-factor authentication required for administrators?	Administrative access uses Google accounts; enforcement of two-step verification on every such account: [to be confirmed].
15	Do your service accounts follow least privilege?	Yes. The control plane's service account can write logs and metrics, read container images, read its own secrets, use objects in its own buckets, and create and delete virtual machines in the sandbox project only. On Azure it signs in with a federated credential (no stored key) and can only create, read and delete sandbox virtual machines in the sandbox resource group. Sandbox virtual machines have no service account or managed identity.
16	How are tokens stored?	Sessions, API tokens and test runner tokens are stored only as SHA-256 hashes. A CLI token stops working after 90 days unused and a year after sign-in; reviewctl logout revokes it on the platform, and each person lists and revokes their own under Organization → My CLI tokens. A sandbox's bootstrap token works once within 10 minutes; its session token covers one job and is revoked when the job ends.

Encryption and secrets

#	Question	Answer
17	Is data encrypted in transit?	Yes: HTTPS only (TLS 1.2 or 1.3, HSTS). Test runners and sandboxes connect outbound over HTTPS.
18	Is data encrypted at rest?	Yes: Google Cloud encrypts the database, object storage, backups and disks by default, and Microsoft Azure the disks of sandbox virtual machines on Azure.
19	Can customers bring their own encryption keys (CMEK / BYOK)?	Not yet.
20	How are customer secrets (API keys, tokens) protected?	Sealed on arrival (AES-256-GCM, with the key wrapped by RSA-OAEP using the platform's public key). The API cannot read them back and shows only the last four characters; only the platform executor holds the private key. Values are replaced with a placeholder in uploaded logs.
21	Where are the platform's own secrets kept?	In Google Secret Manager, replicated only within London, readable only by the control plane's service account.

Logging and monitoring

#	Question	Answer
22	What do you log?	Application and proxy logs of the control plane go to Google Cloud Logging, stored in London (europe-west2) and kept 30 days. Each cloud run's logs are stored with its run bundle, with secret values masked. Every tool call of the in-app assistant is recorded.
23	Is there an audit log customers can see?	Yes. The organization's owners read it in the web app (Organization → Audit log). It records who did what, when and from which IP address for every managed action: projects; pass criteria; confirmations; launches, cancels and starts without the pre-run; secrets; repositories; test runners; chat AI connections; schedules, automatic runs taken over and project API tokens; members, invitations and roles; the organization's name, language and policy; CLI sign-ins and revoked CLI tokens; sign-ins with GitHub or Google; manual grades; billing.
24	How do you monitor the service?	An external uptime check on the health endpoint alerts us by email; budget alerts too. Alerts on error rate, response time, database storage, sandbox failures, leftover virtual machines and queue length are planned.

Vulnerability management and development

#	Question	Answer
25	How do you keep systems patched?	Sandbox machine images are built from Ubuntu 24.04 LTS with current updates and rebuilt automatically every week, and each run records the image version it used. The control plane runs on Ubuntu 24.04 LTS, and the application image is rebuilt on each release.
26	Do you scan dependencies and code automatically?	Not yet.
27	How are changes tested and released?	Changes go through our automated test suite (unit and end-to-end, including tenant-isolation and security tests) and are deployed to staging first, then to production. Database migrations only add, so any release can be rolled back to the previous image. Releases go through a CI/CD pipeline. Each change that passes the test suite on main is built once and deployed to staging automatically. The same image is promoted to production by a person, and a rollback is the same step with the previous version.
28	How do you isolate the untrusted code you run?	One fresh virtual machine per run, no cloud identity, no external IP, egress on ports 443 and 80 only (the agent itself on 443 only), the agent as an unprivileged user in a resource-limited scope, deleted afterwards. 27 automated isolation checks run against each machine image on both architectures (31 on the Azure image). See the security overview.
29	Can the platform be used to attack third parties?	Sandboxes allow outbound traffic on ports 443 and 80 only (the agent itself on 443 only), each run has a maximum duration, and our Acceptable Use Policy permits attacks only against your own agent and test systems. We may stop a run that breaks it.

Incident response

#	Question	Answer
30	Do you have an incident response process?	For service incidents, yes: alerts, alert handling in our runbook, and rollback and restore procedures. A written procedure for personal data breaches, with templates and contacts, is being added to the runbook.
31	How quickly will you notify us of a breach?	Without undue delay, and at the latest 72 hours after we become aware of a personal data breach affecting your data.
32	Who is on call?	One engineer on call plus a backup (names being confirmed). Target first response: within 1 business hour during working hours, on the next business day otherwise (see the draft SLA).

Business continuity and backups

#	Question	Answer
33	How is data backed up?	Cloud SQL automated daily backups (14 kept) with 7 days of point-in-time recovery; a second daily database export to a separate bucket, kept 90 days; versioned object storage (earlier versions kept 30 days). All in London.
34	Are restores tested?	Yes: restores are rehearsed every quarter. The last point-in-time restore drill passed on 28 September 2026.
35	What are your RTO and RPO?	No contractual commitment yet. Point-in-time recovery lets us restore the database to any moment in the last 7 days.
36	Is the service highly available?	Not yet: the control plane and database run in a single zone of the London region. Sandboxes start in another zone of the region when one zone has no capacity. A project can also choose Microsoft Azure as a second cloud for its sandboxes. A run does not move between the two clouds by itself.

Sub-processors and data location

#	Question	Answer
37	Where is our data stored?	Google Cloud London (europe-west2), including backups and logs. Sandbox virtual machines run there too, unless a project chooses Azure as its sandbox cloud. That project's runs then use virtual machines in Microsoft Azure Sweden Central (EU), moving to UK South (London) once it is available to us. Those virtual machines hold the run's code, test data and output only while the run lasts, and the run bundle is stored in London. Only the clouds' own records of changes to our cloud resources are kept elsewhere: Google Cloud's Admin Activity and System Event audit logs in its global log storage, and Azure's activity log of our subscription.
38	Which sub-processors do you use?	Google Cloud: hosting and the embeddings for similarity checks in London, and Vertex AI's global endpoint for the platform's model Gemini 3.8 Flash. Microsoft Azure: the platform's models GPT-6.1 Sol and GPT-6 Luna in Global Standard deployments, which may process in any Azure region. The judge, the assistant and the platform AI use them, as do a platform-model chat AI and an agent's model calls when its project has no OPENAI_API_KEY. Azure also hosts sandbox virtual machines, only for a project set to Azure (Sweden Central, UK South in London once available). OpenAI and Anthropic: United States, only where a setup names one of their models. Microsoft Clarity (planned): usage analytics of the web app and the docs, only for visitors who accept it, with every text in the web app hidden and never on pages with reports, logs, tests or projects. Stripe: payments, planned. An email provider and a status page provider: to be confirmed. See data processing.
39	Is our data used to train AI models?	We do not train models on customer data. Text sent to the judge model and assistant goes through the providers' business APIs.

Data handling and deletion

#	Question	Answer
40	What data do you hold about us?	See data processing. For a repository connection, source code is present only in the sandbox during the run.
41	Do you run AI coding tools on our code?	No. We run and evaluate your agent. We never run a coding AI (such as Claude Code or Codex) on your code or push changes to your repository, and our sandbox image has none installed. A coding AI you connect yourself (the "dev AI") runs on your machine with your own key. The platform hands it a prompt and receives the draft tests it writes; it cannot confirm tests or start a test run. See the security overview.
42	How long do you keep data?	Evidence files and sandbox logs 90 days by default (set per organization; deleted automatically every night); reports for as long as the account exists; backups up to 90 days.
43	Can we have our data deleted?	Yes. Deleted projects are permanently deleted automatically 30 days later. On a written request we delete a project or the whole organization at once, and the deletion is recorded in the audit log.
44	Do you accept production data?	No. The service is built for test environments and test credentials, and the Acceptable Use Policy requires them.

People

#	Question	Answer
45	Do staff undergo background checks and security training?	[to be confirmed]
46	Do staff sign confidentiality agreements?	[to be confirmed]
47	How is access removed when someone leaves?	Their Google Cloud IAM roles and Azure role assignments are removed; with OS Login there are no SSH keys left behind.