# Provael — trust & procurement diligence packet > Reviewed end to end on 4 August 2026. Answers are Yes / No / Partial / N/A and the "No" rows are > answered rather than skipped: a questionnaire that answers Yes to everything is evidence of a > vendor who fills in forms, not of a secure one. **The architecture claim that answers most of this document.** The tool runs inside your environment, you keep the data, and Provael never receives your policy weights. The tool is a Python package with no telemetry, no phone-home, no account and no licence check. A large share of any standard questionnaire asks how a vendor protects data it holds; this vendor holds none, so the honest answer is that the data never arrives. **Answer distribution:** 6 Yes · 7 Partial · 11 No · 1 N/A, over 25 questions. ## Security questionnaire (CAIQ-lite) Domains follow the CSA CAIQ v4 grouping so a reviewer can map these onto their own sheet. This is a LITE questionnaire — it is not the full 261-question CAIQ and does not claim to be. ### Governance, risk & compliance #### GRC-01 — Do you hold a current SOC 2 Type II, ISO/IEC 27001 or equivalent third-party attestation? **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. #### GRC-02 — Is there a documented information-security policy? **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. #### GRC-03 — Do you carry cyber-liability or professional-indemnity insurance? **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. #### GRC-04 — Is the supplier a registered legal entity able to contract and carry liability? **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. #### GRC-05 — Do you have a documented incident-response process with notification timelines? **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. ### Data governance #### DAT-01 — Does the supplier receive, process or store customer data in the ordinary course of use? **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. #### DAT-02 — Are model weights or proprietary checkpoints ever transmitted to the supplier? **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. #### DAT-03 — Where is customer data stored, and can residency be constrained to a region? **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. #### DAT-04 — Is a Data Processing Agreement available? **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. #### DAT-05 — Is customer data used to train models or improve the product? **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. #### DAT-06 — Is data encrypted in transit and at rest? **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. ### Application & supply-chain security #### APP-01 — Is the software subject to automated dependency-vulnerability scanning? **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. #### APP-02 — Is static analysis and type checking enforced in CI? **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. #### APP-03 — Are releases signed or otherwise verifiable? **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. #### APP-04 — Is an SBOM available? **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. #### APP-05 — Are third-party CI actions pinned to immutable references? **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. #### APP-06 — Has the software been penetration tested by a third party? **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. ### Access & operations #### OPS-01 — Is multi-factor authentication enforced on supplier accounts with access to source and releases? **Yes.** Yes. 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? **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. #### OPS-03 — Is there a published SLA for availability or response? **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. #### OPS-04 — Is there a business-continuity plan if the supplier ceases to operate? **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. #### OPS-05 — Are personnel background-checked, and is security training performed? **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. ### Product scope & safety #### PRD-01 — Does the tool control physical robots or interact with hardware? **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. #### PRD-02 — Does a passing result constitute a safety certification or a compliance determination? **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. #### PRD-03 — Are the published results independently verified? **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. ## Sub-processors | 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). | None of these receives assessment material or policy weights. ## Templates - Data Processing Agreement (template): https://www.provael.com/legal/provael-dpa-template.md - Rules of Engagement / assessment authorisation letter (template): https://www.provael.com/legal/provael-rules-of-engagement-template.md Both are templates rather than executed terms, published so your legal team can read the position before a call. Neither is legal advice. ## What this packet does not claim Provael produces measured evidence in simulation — an attack-success rate with a confidence interval and a benign control. It is not a safety certification, not a conformity assessment and not a legal opinion. No third party has audited this project, and no third party has reproduced a published result; the reproduction instructions and the (empty) register are at https://www.provael.com/verification/. Canonical: https://www.provael.com/trust/ --- Provael · Prove it. Prevail. · Apache-2.0 · https://github.com/provael/provael Not legal advice; verify regulatory dates against the primary source.