PROCUREMENT DILIGENCE · REVIEWED 4 AUGUST 2026
The security review, answered in advance.
The free tool runs inside your environment and transmits nothing. A booked assessment runs in your environment, or against an endpoint you host, by default; any transfer of a checkpoint is a written decision under the data processing agreement (DPA), never a default. Every question below is answered, the No rows included.
- 7 Yes
- 6 Partial
- 11 No
- 1 N/A
- 25 questions
Reviewed end to end on , by hand: nothing in this build can detect that a control changed. Answers corrected after that review, on , are not covered by it, and their re-read is pending: DAT-03, DAT-05, DAT-06, APP-03, APP-04, OPS-03 and PRD-03. To attach the packet to a review ticket, download it as Markdown (/trust.md).
The gaps, first
What is missing today
Each line links to its full answer in the questionnaire below.
- Status: NoSOC 2, ISO/IEC 27001 or equivalent attestation. None held, none in progress. If your process requires one to proceed, this is a hard blocker today. Full answer (GRC-01)
- Status: NoCyber-liability or professional-indemnity insurance. No policy is in force as of 20 September 2026. If cover is a condition of your purchase, raise it at the scoping call: it is obtainable, and the answer then becomes a policy number and a limit rather than a reassurance. Full answer (GRC-03)
- Status: PartialLegal entity. Not yet: "Provael" is a project name. A private limited company is being incorporated in Ahmedabad; from its incorporation (expected January 2027) paid contracts are with the company. Until then the counterparty is Sattyam Jain, an individual (India), operating as Provael. Every template below names him as the party until then. Where a buyer requires a corporate counterparty before that, incorporation happens before signature, not after. Full answer (GRC-04)
- Status: NoThird-party penetration test or code audit. None performed. Full answer (APP-06)
- Status: NoIndependent verification of published results. No notified body, certifier, insurer or standards committee has reviewed this work, and no third party has reproduced a published result. The instructions and the empty register are at /verification. Full answer (PRD-03)
Provael is built and maintained by one person. That is a real dependency for anything you rely on. The tool is Apache-2.0 and can be forked, and every result can be reproduced from a committed recipe, so evidence you already hold stays valid if the project stops. One person cannot offer a service level, so none is published.
Where your data goes
What crosses the boundary, per path
There are three paths. On the free tool's path nothing reaches Provael, as the figure shows. This website's forms and a managed engagement do carry something, and the table after the figure says what, where it lands, who can read it and how long it is kept.
- Your environment
- Policy weights, checkpoints, task definitions and run outputs stay here. The provael CLI runs here too, beside them.
- Crosses the boundary
- The evidence pack, and it crosses to you. It is yours to file, keep and share.
- Provael receives, on this path
- Nothing. No weights, no traces, no telemetry, no run data.
The data flow, per path
Each row is what operates today, or the written default of the engagement templates. You can check it against the privacy notice, the two templates below and the product's maintainer procedure.
| Path | What crosses | Where it lands | Who can read it | Retention & deletion | Training use |
|---|---|---|---|---|---|
| The free tool (CLI, GitHub Action, container) | Nothing. No telemetry, no phone-home, no account, no licence check. Policy weights, checkpoints, run outputs and evidence artifacts are produced on your machines and stay there; the optional real-policy loaders fetch public checkpoints from the Hugging Face Hub, outbound from your environment, when you ask them to. | Your disk, your CI cache, your object store. Provael the supplier receives nothing and cannot see that you ran it. | Only whoever you give access to. The source is Apache-2.0 and the network behaviour is inspectable. | Yours to keep or delete; nothing exists on our side to delete. | Not applicable - nothing arrives. |
| This website's request forms (homepage, readiness snapshot, /contact) | The fields you type: name, work email, organisation, stack, milestone, what you want to prove or a message, the offer you chose (intent), the form's own tag (source) and the path of the page it was on (page); plus your country as Cloudflare derives it from your IP and the time of submission. The browser user-agent is not stored (it was, and read by nothing, until 20 September 2026). The form is not for checkpoints, tokens, traces or proprietary prompts, and says so beside the submit button. | A Cloudflare KV store (global edge), the lead backend on Amazon Web Services (a DynamoDB table in us-east-1, reached server-side by a same-origin function), and a notification email through Resend (US) to the monitored inbox. Any one sink capturing the lead is a success; if none does, the page offers a pre-filled email and nothing is stored. | One person - the maintainer - through the Cloudflare and AWS consoles and the inbox. No third party reads the submissions. | Submissions expire automatically 730 days after receipt in both stores; the per-IP rate-limit counter expires after two hours; the notification email is kept only as long as needed to respond. Earlier deletion on request (see /privacy). | Never used to train anything. |
| A managed engagement (Checkpoint Report or assessment) | By default, nothing that identifies your policy: the maintainer executes inside your environment, or against an endpoint you host, and receives the evidence pack you also receive. Where you decide in writing to transfer a checkpoint or traces instead, the rules-of-engagement letter names what, the DPA governs it, and the transfer is made over a channel you approve - never through this website. | Your environment by default. A transferred artifact lands only in the agreed isolated environment the work order names (the maintainer's workstation or a rented GPU box under his control), with the location recorded in the engagement file. | The maintainer, and nobody else, for the scope and time the rules-of-engagement letter states. No sub-processor receives assessment material. | Transferred material is deleted within 30 days of final delivery unless you instruct otherwise in writing, with deletion confirmed in writing; the evidence pack and the engagement file are kept as the record of the work. Requests to delete earlier are honoured. | Never used to train, tune or evaluate anything beyond the agreed protocol. |
Customer data handling is agreed before access: the rules-of-engagement letter ticks which path applies, and a transferred checkpoint is a written decision with a deletion date, never a default and never a form upload.
Questionnaire
The questionnaire, answered
The questions follow the domains of the Cloud Security Alliance's Consensus Assessments Initiative Questionnaire (CSA CAIQ v4), so you can map them onto your own sheet. This is a short version, CAIQ-lite: it is not the full 261-question CAIQ and does not claim to be. Where a question cannot be answered honestly with a Yes, it is not.
Governance, risk & compliance
| Ref | Question | Answer |
|---|---|---|
| GRC-01 | Do you hold a current SOC 2 Type II, ISO/IEC 27001 or equivalent third-party attestation? | Status: NoThere is no SOC 2, no ISO/IEC 27001 and no third-party security audit of this project, and none is in progress as of 20 September 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.Outlook: None scheduled. A Type II audit is reconsidered at the point a buyer’s process makes it a condition of purchase and the engagement pays for it; until then the controls are documented publicly instead (SAFETY.md, /security, this page). |
| GRC-02 | Is there a documented information-security policy? | Status: PartialSecurity 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 information-security management system (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: NoNone is in force as of 20 September 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.Plan: Professional-indemnity cover is bound at the signature of the earliest paid contract and reflected in fees (/pricing states the same commitment). The policy number and limit replace this row the day it exists. By: the signature of the earliest paid contract. |
| GRC-04 | Is the supplier a registered legal entity able to contract and carry liability? | Status: PartialNot yet: "Provael" is a project name, and contracting today is with the individual maintainer personally — Sattyam Jain, an individual (India), operating as Provael. A private limited company is being incorporated in Ahmedabad (confirmed 20 September 2026; expected January 2027), and paid contracts move to it from its incorporation. Every template on this page names him as the party until then. For a buyer that requires a corporate counterparty before that, incorporation is a prerequisite of the engagement and is handled before signature, not after; no registration, insurance or certification is implied anywhere on this site until it exists. |
| GRC-05 | Do you have a documented incident-response process with notification timelines? | Status: PartialA vulnerability-disclosure process with a stated response window is published at /security and is exercised. A standard agreement carries no contractual service level (SLA) for breach notification, 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
| Ref | Question | Answer |
|---|---|---|
| DAT-01 | Does the supplier receive, process or store customer data in the ordinary course of use? | Status: NoThe 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.Outlook: By design: the tool is a local package with no telemetry. This No does not change; a hosted surface, if a customer ever requires one, would carry its own row. |
| DAT-02 | Are model weights or proprietary checkpoints ever transmitted to the supplier? | Status: NoFor 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.Outlook: By design: execution in your environment is the default and a transferred checkpoint is a written decision under the DPA. This No does not change. |
| DAT-03 | Where is customer data stored, and can residency be constrained to a region? | Status: N/AThe tool 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, in a Cloudflare KV store at the global edge and in the US (Amazon Web Services in us-east-1, and Resend for the notification email). |
| DAT-04 | Is a data processing agreement (DPA) available? | Status: YesA 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: NoIt could not be: no customer data is received. Findings from an assessment are published only where a design-partner agreement grants that explicitly, and /case-studies states exactly what anonymisation removes before anything is published.Outlook: By design: no customer data is received, so none can train anything. This No does not change. |
| DAT-06 | Is data encrypted in transit and at rest? | Status: PartialScoped 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 can be integrity-protected by an 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
| Ref | Question | Answer |
|---|---|---|
| APP-01 | Is the software subject to automated dependency-vulnerability scanning? | Status: YesEvery 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: YesEvery pull request is gated by ruff (lint and import order), mypy in strict mode over the source tree, and the full test suite. 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: YesReleases publish to PyPI through OpenID Connect (OIDC) trusted publishing, so no long-lived API token exists to steal, and PyPI carries signed provenance attestations for the wheel and the sdist. Each GitHub release asset (the wheel, the sdist, the SBOM and the checksum file) also carries a keyless Sigstore signature bundle and a build-provenance attestation that names the workflow, the tag and the commit that built it. Evidence artifacts the tool emits can be Ed25519-signed and verified offline. |
| APP-04 | Is a software bill of materials (SBOM) available? | Status: YesEach GitHub release ships a CycloneDX SBOM of the package environment (generated in the release workflow with cyclonedx-py) beside the wheel, the sdist and SHA-256 checksums; the tool can also emit a CycloneDX ML-BOM for any run, and the dependency set is fully pinned in a committed lockfile. |
| APP-05 | Are third-party CI actions pinned to immutable references? | Status: YesEvery 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: NoNeither a third-party penetration test nor a 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; it does not change the answer.Outlook: A third-party test is commissioned if and when a hosted server ships; the in-repo server is an experimental reference and does not. No hosted surface is planned before a customer requires one, so there is no date, and this row says so rather than promising one. |
Access & operations
| Ref | Question | Answer |
|---|---|---|
| OPS-01 | Is multi-factor authentication enforced on supplier accounts with access to source and releases? | Status: YesMFA 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: PartialEngagement-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 service-level agreement (SLA) for availability or response? | Status: NoNone is published, because a single maintainer cannot honour one and publishing an SLA that cannot be honoured is worse than publishing none.Outlook: No public SLA while there is one maintainer; the assurance subscription sets response expectations contractually, per agreement. A public SLA follows a second maintainer, for which there is no date. |
| OPS-04 | Is there a business-continuity plan if the supplier ceases to operate? | Status: PartialThe 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: NoThere is one person and no HR process; no background check or formal security training programme exists.Outlook: A background-check and training practice starts with the second person; there is no date for a second person. Until then the answer stays No and the mitigation is that no customer data is held to be mishandled. |
Product scope & safety
| Ref | Question | Answer |
|---|---|---|
| PRD-01 | Does the tool control physical robots or interact with hardware? | Status: NoEvery 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.Outlook: By design, documented in SAFETY.md: simulation only, no hardware control path. This No does not change. The one pre-registered real-arm study (sim-to-real, SO-ARM101) is a measurement of a policy, not a control path in the tool. |
| PRD-02 | Does a passing result constitute a safety certification or a compliance determination? | Status: NoThe 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.Outlook: By design: Provael produces evidence, and an assessor or notified body decides. This No does not change. |
| PRD-03 | Are the published results independently verified? | Status: NoThis work has not been reviewed by a notified body, certification body, insurer or standards committee, 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.Plan: Two routes. Peer review is a dated proof on /roadmap: the SPAIS@CoRL four-pager was submitted before the 1 October 2026 deadline and not accepted (notified 17 October 2026), and it goes on arXiv in November regardless of the decision. Independent reproduction: the packs and the how-to-report route are on /reproduce, and the register at /verification is empty, dated. Neither is a certification body, and the row says No until one of them exists. By: November 2026 (the arXiv posting); the register moves when a reproduction is reported. |
Sub-processors
Every third party, and exactly what it touches
The list includes the providers that touch nothing of yours, so no infrastructure row is left out.
| Sub-processor | Purpose | What it touches | Location |
|---|---|---|---|
| Cloudflare | Hosts and serves this website; runs the server-side functions behind the contact form and the five first-party event counters (one integer per event name per day in KV); Web Analytics at the edge when enabled, cookieless. | Website traffic metadata, the fields you type into a contact form in transit, and event names with no identifier attached. | 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. | US (us-east-1). |
| 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 scoping call: the booking buttons open a Cal.com page. | The name, email, time and any notes you enter to book a call. | EU/US. |
| Buttondown | Sends the email newsletter you can subscribe to on this website. | The email address you subscribe with. Every issue carries an unsubscribe link. | 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; on a managed engagement, transferred material stays in the agreed environment the work order names (see the data flow, per path).
Legal templates
Templates your legal team can redline
Published so counsel can read the position before a call rather than after one. Neither template is legal advice, and neither is executed terms.
- Data Processing Agreement (template)Markdown · covers the two narrow cases where personal data genuinely is processed: contact details from this site, and anything incidental inside assessment material.
- Rules of Engagement / authorisation letter (template)Markdown · names the target, the window, the stop procedure and the seven things that are explicitly not authorised, starting with any operation of physical robot hardware.
- This packet as one file (Markdown)The whole questionnaire and sub-processor list, for attaching to a review ticket.
On PDFs. The packet is Markdown rather than PDF on purpose: /trust.md renders from the same source as this page, so it cannot quietly drift from the answers above. If your process needs a PDF, print this page, or ask and you will get one generated from exactly this text.
On corrections. Published claims that turned out to be wrong are logged, dated and never removed, on errata.
Next step
If this clears your review
Talk to a person about scope, or first read the core of the deliverable, in full rather than summarised, on /sample-evidence-pack. Prices are on /pricing.
Provael produces measured evidence in simulation. It is not a safety certification, not a conformity assessment and not a legal opinion. Nothing on this page is legal advice.