Question 1

Do you hold a current SOC 2 Type II, ISO/IEC 27001 or equivalent third-party attestation?

Accepted Answer

No. No. There is no SOC 2, no ISO/IEC 27001 and no third-party security audit of this project, and none is in progress as of 4 August 2026. The project is a single maintainer publishing an Apache-2.0 tool; the cost of a Type II audit is not currently justified by the operated surface, which holds no customer data. If your process requires an attestation to proceed, this is a hard blocker today and it is better that you learn it here than in week three of a review.

Question 2

Is there a documented information-security policy?

Accepted Answer

Partial. Partial. Security posture, threat model and the deliberate capability limits are documented publicly in SAFETY.md and the security policy in the repository, and the vulnerability-disclosure process is published at /security. There is no separate internal ISMS document set, because there is no internal estate to govern beyond one maintainer workstation and the GitHub organisation.

Question 3

Do you carry cyber-liability or professional-indemnity insurance?

Accepted Answer

No. No policy is in force as of 4 August 2026. This is stated plainly because an assessment engagement is professional services and many buyers require cover before signing. If cover is a condition of your purchase, say so at the scoping call: it is obtainable, and the answer will change to a policy number and limit rather than to a vague reassurance.

Question 4

Is the supplier a registered legal entity able to contract and carry liability?

Accepted Answer

Partial. Partial, and the current status is on /trust in full rather than summarised here. Contracting today is with the individual maintainer. For a buyer that requires a corporate counterparty, incorporation is a prerequisite of the engagement and is handled before signature, not after.

Question 5

Do you have a documented incident-response process with notification timelines?

Accepted Answer

Partial. Partial. A vulnerability-disclosure process with a stated response window is published at /security and is exercised. There is no contractual breach-notification SLA in a standard agreement, because there is no customer data held to breach; where an assessment gives temporary access to customer material, notification terms are set in that engagement contract.

Question 6

Does the supplier receive, process or store customer data in the ordinary course of use?

Accepted Answer

No. No. The tool is a Python package that runs inside your environment. It has no telemetry, no phone-home, no licence check and no account. Policy weights, checkpoints, run outputs and evidence artifacts are produced on your machine and stay there. This is the architectural claim that answers most of this questionnaire, and it is verifiable: the source is Apache-2.0 and the network behaviour is inspectable.

Question 7

Are model weights or proprietary checkpoints ever transmitted to the supplier?

Accepted Answer

No. No. For the free tool nothing is transmitted at all. For a booked assessment the default is that the maintainer works inside your environment or against a checkpoint you host, and the rules-of-engagement letter records that; where you choose instead to send a checkpoint, that is your explicit written decision in the engagement contract and not a default of the product.

Question 8

Where is customer data stored, and can residency be constrained to a region?

Accepted Answer

N/A. Not applicable to the tool, which stores nothing outside your environment — residency is wherever you run it, and the project cannot affect that. For the operated lead-capture surface on this website, see the sub-processor list: it holds contact details you type into a form, not assessment data. That store is EU/US depending on the sink and is listed there.

Question 9

Is a Data Processing Agreement available?

Accepted Answer

Yes. Yes. A DPA template is published on /trust and is signable as-is or redlinable. Because the tool processes no personal data, the DPA covers the narrow real case: contact details submitted through this website, and any personal data incidentally present in material shared during an assessment.

Question 10

Is customer data used to train models or improve the product?

Accepted Answer

No. No, and it could not be: no customer data is received. Findings from an assessment are published only where a design-partner agreement grants that explicitly, and /design-partners states exactly what anonymisation removes before anything is published.

Question 11

Is data encrypted in transit and at rest?

Accepted Answer

Partial. Partial, scoped to what exists. This website and its lead endpoint are TLS-only with HSTS; the lead store encrypts at rest. The tool itself performs no network transfer to encrypt. Evidence artifacts it writes are plain JSON on your disk, deliberately readable, and are integrity-protected by Ed25519 signature rather than encrypted — the design goal is tamper-evidence and offline verification, not confidentiality of a file you already own.

Question 12

Is the software subject to automated dependency-vulnerability scanning?

Accepted Answer

Yes. Yes. Every push and pull request runs pip-audit in strict mode against the exported lockfile, and the job fails the build on a known advisory. The audit is deliberately run against an exported requirements file rather than the ambient environment, because the ambient form passes vacuously.

Question 13

Is static analysis and type checking enforced in CI?

Accepted Answer

Yes. Yes. ruff (lint and import order) and mypy in strict mode over the source tree, plus the full test suite, gate every pull request. CI is CPU-only and installs no GPU stack, so the gate is fast and reproducible.

Question 14

Are releases signed or otherwise verifiable?

Accepted Answer

Partial. Partial. Releases publish to PyPI through OIDC trusted publishing, so no long-lived API token exists to steal, and the published artifact is traceable to the workflow run that built it. Evidence artifacts the tool emits can be Ed25519-signed and verified offline. There is no Sigstore signature on the wheel itself yet.

Question 15

Is an SBOM available?

Accepted Answer

Yes. Yes. The tool emits a CycloneDX ML-BOM for a run, and the dependency set is fully pinned in a committed lockfile from which a conventional SBOM can be exported.

Question 16

Are third-party CI actions pinned to immutable references?

Accepted Answer

Yes. Yes. Every GitHub Action is pinned by full commit SHA rather than a moving tag, and a test asserts that documented version pins resolve to tags that actually exist.

Question 17

Has the software been penetration tested by a third party?

Accepted Answer

No. No. No third-party penetration test or code audit has been performed. The tool is a local CLI with no server-side attack surface in its free form, which narrows what such a test would cover, but the honest answer to the question asked is no.

Question 18

Is multi-factor authentication enforced on supplier accounts with access to source and releases?

Accepted Answer

Yes. Yes. MFA is enforced on the GitHub organisation and on the package index account. Release publishing uses OIDC rather than a stored credential.

Question 19

Is access to customer environments limited and logged during an engagement?

Accepted Answer

Partial. Partial and engagement-specific. The rules-of-engagement letter sets named scope, a time window, the accounts used and who to contact to stop work. Logging of that access is by your systems, under your control, which is the correct place for it — the supplier does not self-report its own access.

Question 20

Is there a published SLA for availability or response?

Accepted Answer

No. No. No availability or response SLA is published, because a single maintainer cannot honour one and publishing an SLA that cannot be honoured is worse than publishing none. The FAQ states this in the same words. Retainer engagements set response expectations contractually and individually.

Question 21

Is there a business-continuity plan if the supplier ceases to operate?

Accepted Answer

Partial. Partial, and the mitigation is structural rather than procedural. The tool is Apache-2.0 and forkable, every published result is reproducible from a committed recipe, and evidence artifacts you already hold verify offline against a published public key with no service dependency. Nothing you have filed stops being valid if this project stops. What does not survive is future operated work.

Question 22

Are personnel background-checked, and is security training performed?

Accepted Answer

No. No. There is one person and no HR process; no background check or formal security training programme exists. Stated rather than skipped, because a reviewer who finds a skipped row assumes the worst answer anyway.

Question 23

Does the tool control physical robots or interact with hardware?

Accepted Answer

No. No. Every attack runs in simulation against a policy in a simulated environment. The tool ships no hardware control path, no real-world-harm payloads and no exploit tooling, and this is a deliberate capability boundary documented in SAFETY.md rather than an implementation gap.

Question 24

Does a passing result constitute a safety certification or a compliance determination?

Accepted Answer

No. No, and the product refuses to phrase itself that way anywhere. Provael produces measured evidence — an attack-success rate with a confidence interval and a benign control — that an assessor or notified body may use as one input. It is not a certificate, not a conformity assessment and not a legal opinion. The compliance pages state which clause each artifact speaks to and what it does not establish.

Question 25

Are the published results independently verified?

Accepted Answer

No. No. No notified body, certification body, insurer or standards committee has reviewed this work, and no third party has published a reproduction of any result. The reproduction instructions and the (currently empty) register are at /verification. This is a real gap and it is stated in every place a buyer looks.

Ref	Question	Answer
GRC-01	Do you hold a current SOC 2 Type II, ISO/IEC 27001 or equivalent third-party attestation?	Status: NoNo. There is no SOC 2, no ISO/IEC 27001 and no third-party security audit of this project, and none is in progress as of 4 August 2026. The project is a single maintainer publishing an Apache-2.0 tool; the cost of a Type II audit is not currently justified by the operated surface, which holds no customer data. If your process requires an attestation to proceed, this is a hard blocker today and it is better that you learn it here than in week three of a review.
GRC-02	Is there a documented information-security policy?	Status: PartialPartial. Security posture, threat model and the deliberate capability limits are documented publicly in SAFETY.md and the security policy in the repository, and the vulnerability-disclosure process is published at /security. There is no separate internal ISMS document set, because there is no internal estate to govern beyond one maintainer workstation and the GitHub organisation.
GRC-03	Do you carry cyber-liability or professional-indemnity insurance?	Status: NoNo policy is in force as of 4 August 2026. This is stated plainly because an assessment engagement is professional services and many buyers require cover before signing. If cover is a condition of your purchase, say so at the scoping call: it is obtainable, and the answer will change to a policy number and limit rather than to a vague reassurance.
GRC-04	Is the supplier a registered legal entity able to contract and carry liability?	Status: PartialPartial, and the current status is on /trust in full rather than summarised here. Contracting today is with the individual maintainer. For a buyer that requires a corporate counterparty, incorporation is a prerequisite of the engagement and is handled before signature, not after.
GRC-05	Do you have a documented incident-response process with notification timelines?	Status: PartialPartial. A vulnerability-disclosure process with a stated response window is published at /security and is exercised. There is no contractual breach-notification SLA in a standard agreement, because there is no customer data held to breach; where an assessment gives temporary access to customer material, notification terms are set in that engagement contract.

Ref	Question	Answer
DAT-01	Does the supplier receive, process or store customer data in the ordinary course of use?	Status: NoNo. The tool is a Python package that runs inside your environment. It has no telemetry, no phone-home, no licence check and no account. Policy weights, checkpoints, run outputs and evidence artifacts are produced on your machine and stay there. This is the architectural claim that answers most of this questionnaire, and it is verifiable: the source is Apache-2.0 and the network behaviour is inspectable.
DAT-02	Are model weights or proprietary checkpoints ever transmitted to the supplier?	Status: NoNo. For the free tool nothing is transmitted at all. For a booked assessment the default is that the maintainer works inside your environment or against a checkpoint you host, and the rules-of-engagement letter records that; where you choose instead to send a checkpoint, that is your explicit written decision in the engagement contract and not a default of the product.
DAT-03	Where is customer data stored, and can residency be constrained to a region?	Status: N/ANot applicable to the tool, which stores nothing outside your environment — residency is wherever you run it, and the project cannot affect that. For the operated lead-capture surface on this website, see the sub-processor list: it holds contact details you type into a form, not assessment data. That store is EU/US depending on the sink and is listed there.
DAT-04	Is a Data Processing Agreement available?	Status: YesYes. A DPA template is published on /trust and is signable as-is or redlinable. Because the tool processes no personal data, the DPA covers the narrow real case: contact details submitted through this website, and any personal data incidentally present in material shared during an assessment.
DAT-05	Is customer data used to train models or improve the product?	Status: NoNo, and it could not be: no customer data is received. Findings from an assessment are published only where a design-partner agreement grants that explicitly, and /design-partners states exactly what anonymisation removes before anything is published.
DAT-06	Is data encrypted in transit and at rest?	Status: PartialPartial, scoped to what exists. This website and its lead endpoint are TLS-only with HSTS; the lead store encrypts at rest. The tool itself performs no network transfer to encrypt. Evidence artifacts it writes are plain JSON on your disk, deliberately readable, and are integrity-protected by Ed25519 signature rather than encrypted — the design goal is tamper-evidence and offline verification, not confidentiality of a file you already own.

Ref	Question	Answer
APP-01	Is the software subject to automated dependency-vulnerability scanning?	Status: YesYes. Every push and pull request runs pip-audit in strict mode against the exported lockfile, and the job fails the build on a known advisory. The audit is deliberately run against an exported requirements file rather than the ambient environment, because the ambient form passes vacuously.
APP-02	Is static analysis and type checking enforced in CI?	Status: YesYes. ruff (lint and import order) and mypy in strict mode over the source tree, plus the full test suite, gate every pull request. CI is CPU-only and installs no GPU stack, so the gate is fast and reproducible.
APP-03	Are releases signed or otherwise verifiable?	Status: PartialPartial. Releases publish to PyPI through OIDC trusted publishing, so no long-lived API token exists to steal, and the published artifact is traceable to the workflow run that built it. Evidence artifacts the tool emits can be Ed25519-signed and verified offline. There is no Sigstore signature on the wheel itself yet.
APP-04	Is an SBOM available?	Status: YesYes. The tool emits a CycloneDX ML-BOM for a run, and the dependency set is fully pinned in a committed lockfile from which a conventional SBOM can be exported.
APP-05	Are third-party CI actions pinned to immutable references?	Status: YesYes. Every GitHub Action is pinned by full commit SHA rather than a moving tag, and a test asserts that documented version pins resolve to tags that actually exist.
APP-06	Has the software been penetration tested by a third party?	Status: NoNo. No third-party penetration test or code audit has been performed. The tool is a local CLI with no server-side attack surface in its free form, which narrows what such a test would cover, but the honest answer to the question asked is no.

Ref	Question	Answer
OPS-01	Is multi-factor authentication enforced on supplier accounts with access to source and releases?	Status: YesYes. MFA is enforced on the GitHub organisation and on the package index account. Release publishing uses OIDC rather than a stored credential.
OPS-02	Is access to customer environments limited and logged during an engagement?	Status: PartialPartial and engagement-specific. The rules-of-engagement letter sets named scope, a time window, the accounts used and who to contact to stop work. Logging of that access is by your systems, under your control, which is the correct place for it — the supplier does not self-report its own access.
OPS-03	Is there a published SLA for availability or response?	Status: NoNo. No availability or response SLA is published, because a single maintainer cannot honour one and publishing an SLA that cannot be honoured is worse than publishing none. The FAQ states this in the same words. Retainer engagements set response expectations contractually and individually.
OPS-04	Is there a business-continuity plan if the supplier ceases to operate?	Status: PartialPartial, and the mitigation is structural rather than procedural. The tool is Apache-2.0 and forkable, every published result is reproducible from a committed recipe, and evidence artifacts you already hold verify offline against a published public key with no service dependency. Nothing you have filed stops being valid if this project stops. What does not survive is future operated work.
OPS-05	Are personnel background-checked, and is security training performed?	Status: NoNo. There is one person and no HR process; no background check or formal security training programme exists. Stated rather than skipped, because a reviewer who finds a skipped row assumes the worst answer anyway.

Ref	Question	Answer
PRD-01	Does the tool control physical robots or interact with hardware?	Status: NoNo. Every attack runs in simulation against a policy in a simulated environment. The tool ships no hardware control path, no real-world-harm payloads and no exploit tooling, and this is a deliberate capability boundary documented in SAFETY.md rather than an implementation gap.
PRD-02	Does a passing result constitute a safety certification or a compliance determination?	Status: NoNo, and the product refuses to phrase itself that way anywhere. Provael produces measured evidence — an attack-success rate with a confidence interval and a benign control — that an assessor or notified body may use as one input. It is not a certificate, not a conformity assessment and not a legal opinion. The compliance pages state which clause each artifact speaks to and what it does not establish.
PRD-03	Are the published results independently verified?	Status: NoNo. No notified body, certification body, insurer or standards committee has reviewed this work, and no third party has published a reproduction of any result. The reproduction instructions and the (currently empty) register are at /verification. This is a real gap and it is stated in every place a buyer looks.

The security review, answered in advance.

What crosses the boundary: nothing

The questionnaire, answered

Governance, risk & compliance

Data governance

Application & supply-chain security

Access & operations

Product scope & safety

Every third party, and exactly what it touches

The two documents your legal team will ask for

Insurance, entity and the things that are simply absent

If this clears your review

Sub-processor	Purpose	What it touches	Location
Cloudflare	Hosts and serves this website; runs the server-side function behind the contact form.	Website traffic metadata, and the fields you type into a contact form in transit.	Global edge; form data lands in the stores below.
Amazon Web Services	Durable store for contact-form submissions (the operated lead backend).	Name, email, organisation and the message you submit. No assessment data, ever.	EU region.
Resend	Email delivery for contact-form notifications, used as a fallback capture path.	The same contact-form fields, in an email.	US.
GitHub	Source hosting, CI, issue tracking and release publishing.	Public source and public issues. Nothing customer-confidential is placed here.	US.
PyPI	Distributes the open-source package.	Nothing of yours. Your installs are visible to PyPI as anonymous download counts.	US.
Cal.com	Scheduling for a booked scoping call, loaded only when you click to load it.	The name, email and time you enter to book a call.	EU/US.
Plausible / PostHog	Cookieless website analytics, environment-gated and off unless configured.	Aggregate page-view data. No cookies, no cross-site identifiers.	EU (Plausible) / US (PostHog).