What you have to trust, stated plainly.
For the security, IT, and procurement review. Where the keys live, what Pask can and cannot touch, and an honest line between what is attested, what is mapped, and what is still on the roadmap.
Certified, mapped, or roadmap.
Three words carry different weight in a review. Here is which one applies to Pask today, without the blur.
- Certified
- Independently audited and attested. Pask holds no SOC 2 or ISO 27001 attestation today. It is pre-pilot, and an attestation needs an audit window and an auditor. We will not badge one we have not earned.
- Mapped
- Our controls are mapped to the frameworks your review already uses (SOC 2, ISO 27001, NIST, HIPAA, the EU AI Act) in the crosswalk below. A mapping is a starting point for your assessment, not a substitute for an attestation. Validate it against your own control set.
- Roadmap
- Designed, dated, and honest about not yet being built. The live capability status marks each capability Working, Reference, Roadmap, or Pilot target, so nothing on this site is claimed before it runs.
Data handling.
- Where the key lives
- Generated inside a secure chip in an appliance the site owns. It is non-exportable: no operator, no cloud, and not Pask ever receives a usable copy. Pask holds no keys.
- What Pask can touch
- The appliance reads devices out of band and read-only, and writes each sealed record outward through a WRITE_ONLY adapter. It never reads back from your systems and is never in the path of a robot command.
- What is at risk in a breach
- There is no central store of your data to exfiltrate. Records live on your site, on your keys. An offline verifier reproduces every check with no account and no call to us.
- Data used to train
- None. Pask writes and verifies records; it does not train models on your operations.
Control-framework crosswalk.
Where each Pask control lands against the frameworks your assessment runs on. Mapped, not attested. Bring it to your own reviewer.
Every Engagement-Receipt field group, mapped to the named control(s) it is evidence for. Pick a framework; click any mapped cell to see the receipt field ↔ control detail. Greyed cells are no-coverage.
| Receipt field group | SOC 2 control(s) |
|---|---|
§5.1header · prior_receipt_hash | CC7.2System monitoring / anomaly detection |
§5.2identity · tee_identity | CC6.8Unauthorized/malicious software controls |
§5.4approval · approving_party / approval_basis | CC6.1Logical access authorization |
§5.5rats · attestation evidence | CC7.1Detection of configuration changes |
§5.6execution · executing_agents / outcome_state | CC7.2System monitoring |
§5.9-5.10validator + reviewer signatures | CC7.3Evaluation of security events |
§5.11seal · pask_seal signatures | CC7.2System monitoring |
compliancecompliance · consent / disclosure basis | P4.0Privacy: use, retention & disposal |
Swipe the table for the mapped controls →
Control identifiers are indicative and should be validated against your own control framework with your auditor. A receipt field is evidence toward a control, not an attestation of compliance by itself.
Every receipt on this page was sealed with real keys on Pask’s own reference site, a staged deployment we built and operate. The cryptography is real. The customer, so far, is us.
Billy McKenzie and Rob Wilder, founders