SOC 2
No SOC 2 Type I or Type II examination has been carried out and no report exists. If your procurement process requires one, raise it early rather than at contract review.
SOC 2 is an attestation by an independent auditor, not something an organisation can self-assert, so every row below is unexamined by definition. What the rows do say is which of the underlying controls actually exist, so you can judge the substance separately from the certificate. Note also that for self-hosted software most of what such a report would cover, the security and availability of the system holding your records, is operated by you rather than by us, so a SOC 2 report about PezPC would say remarkably little about your own install.
This expands one row of the standards table in the main privacy policy. The standard itself is published by its own authority: AICPA.
4 in place 8 partial 1 not in place
Common criteria (Security)
| CC1 | Control environment | Partial | A very small team with clearly held responsibility, which removes whole classes of control-environment failure and creates others. There is no board, no documented organisational structure and no formal accountability matrix to evidence. |
| CC2 | Communication and information | In place | Obligations and practices are communicated publicly and in detail: this set of pages is the artefact. Customers are told what is collected before they use a feature, not afterwards. |
| CC3 | Risk assessment | Not in place | No documented risk assessment, risk register or periodic review. Risks are considered when designing a feature, and that reasoning is often recorded in the code and its history, but that is not what the criterion asks for. |
| CC4 | Monitoring activities | Partial | Errors and email delivery failures are surfaced in administration screens and reviewed. There is no independent evaluation of controls and no internal audit function. |
| CC5 | Control activities | Partial | Technical controls exist and are described throughout these pages. They are not mapped to a control framework or evidenced on a cycle, which is what an examination would test. |
| CC6 | Logical and physical access controls | In place | Least-privilege permissions with no bypass, multi-factor authentication, step-up before credential reveal, salted password hashes, secrets encrypted at rest under keys held outside the database, TLS everywhere, and per-account scoping on every query. |
| CC7 | System operations | Partial | Failures are logged with enough context to reconstruct them, and webhook processing has an explicit retry and dead-letter path so a payment event is never silently lost. There is no formal incident management process or on-call rotation. |
| CC8 | Change management | Partial | All changes go through source control with recorded reasoning, a build pipeline, and a deliberate release step. There is no formal approval gate or documented per-change rollback plan. |
| CC9 | Risk mitigation | Partial | Vendor risk is mitigated mainly by architecture rather than by paperwork: card data never reaches us, customer records never leave the customer's server, and the supplier list is short and published. There is no formal vendor risk assessment programme. |
Additional trust services criteria
| A1 | Availability | Partial | There is no published service level commitment for the portal or the licence server, and no capacity planning process. This matters less than it would for hosted software: an install that cannot reach the licence server keeps working through an offline grace window rather than stopping, which is a deliberate design choice. |
| C1 | Confidentiality | In place | Confidential information is identified, encrypted at rest where it is secret, restricted to staff who need it, and destroyed on account deletion for the categories the policy names. |
| PI1 | Processing integrity | In place | Billing is the processing that has to be right, and it is reconciled against Stripe as the source of truth through an idempotent webhook ledger with retry and dead-lettering, plus a restore path that can rebuild local state from Stripe. |
| P1-P8 | Privacy | Partial | The privacy criteria are the ones we can speak to most directly, because the whole privacy policy is written against them: notice, choice and consent, collection, use and retention, access, disclosure, quality, and monitoring. Retention and disposal is the weak point and is recorded as such. Australian Privacy Principles · How long we keep things |