No audit, no certifications, and everything you can check instead
PLAYBOOX holds no third-party security certification and has never been audited by one. Rather than leave you to discover that, this page states it first, then sets out the control set, what a stranger can verify without asking us, and what would have to be true for each certification to be real.
Why this page opens with what is missing
A vendor trust page normally opens with badges. This one cannot, because there are none to show: no ISO 27001, no SOC 2, no PCI-DSS attestation, no third-party penetration test on file. Saying so in the first paragraph is not modesty — it is the only way the rest of the page is worth reading.
What replaces a badge is not an adjective. It is a set of things a stranger can resolve, read or measure without our help, and a control set specific enough to argue with. Both are below, and where a control is narrower than its name suggests, the narrower version is what is written.
There is a second absence worth stating in the same breath. PLAYBOOX has no paying external customer yet. The platform runs a live consumer service, which is a different claim and a checkable one, and every reference to it on this site means that and not more.
What you can check without asking us
Each row is something you can resolve, read or measure yourself. Nothing on this page rests on a claim you would have to take our word for.
| What | How to check it | What it demonstrates |
|---|---|---|
| The consumer service is live | Resolve www.playboox.net in a browser | The platform runs a real service with real viewers, not a demo build |
| The admin console is live | Resolve admin.playboox.net | The operator-facing half exists and is deployed, not designed |
| The architecture is published in full | Read the 33 engineering pages listed in the sitemap | The design is open to being argued with, including its trade-offs |
| Capabilities are published with their limits | Read /platform/features — 55 capabilities, each with a status | What is not built is listed beside what is, on the same page |
| Cost claims come from published rate cards | Follow the source links on /economics to the vendor's own pricing | The economics argument uses somebody else's numbers, dated |
| Playback figures are measured, not modelled | Read the measurement window printed beside them on the homepage | Every performance number states what it was read from and over what period |
| The applications are published under an operator account | Look at who publishes the listing in the store | Store ownership is a delivery practice here, not a feature flag |
Certifications, one row each
Named individually rather than summarised, because a summary is how the one a buyer needs gets skipped.
| Standard | Status | What we do instead, and what it would take |
|---|---|---|
| ISO/IEC 27001 | Not held | No certification body has assessed the ISMS, because there is no documented ISMS to assess. It is achievable and it is a programme of work, not a document |
| SOC 2 Type II | Not held | No audit has been run and no observation period has started. The control set below is the substance a Type II would examine; what is missing is the independent examination |
| PCI-DSS | Not held — and out of scope by design | Card data never reaches this platform. Payment is handed to the gateway's own hosted page and the platform stores a transaction reference, so the cardholder environment is the gateway's |
| GDPR | Not a certification — a posture | Nothing here is certifiable; what matters is where subscriber data sits and who processes it, which the deployment model decides. Set out below |
| HIPAA | Not held — not applicable | No protected health information passes through a video platform of this shape. Named here so its absence is not read as an oversight |
| VPAT / ADA / WCAG | No VPAT published | No accessibility conformance report has been produced. The site itself is measured against WCAG contrast on every route in both themes as part of its build gate; the applications have had no equivalent audit |
| Third-party penetration test | None on file | No external test has been commissioned. This is the single cheapest item on this page to change, and it is the one a security reviewer asks for first |
The control set, at the width it actually holds
Content is encrypted with AES-128 per title. The decryption key is released only against a signed, expiring token, and the delivery edge re-checks that token on every segment rather than once at the start of playback — so a copied playlist URL does not carry access with it. What this is not is licensed DRM: there is no Widevine, PlayReady or FairPlay licence server in the platform, which is stated here and on every other page that touches the subject.
The origin answers the delivery tier and nothing else. There is no public route to it, so a leaked object path leads nowhere reachable.
Secrets are held in a vault and injected at run time rather than committed or baked into images. The narrower truth, and it belongs here rather than in a footnote: the vault is deployed and running, and some services still read a secrets file, with the vault as the migration target. That is a partial control, and calling it complete would be the kind of claim this page exists to avoid.
Service-to-service calls carry scoped credentials, mutating endpoints are gated, and the public API surface is a deliberate fraction of the total rather than an accident of routing. Infrastructure changes are declared in Terraform and read before they are applied, which means a change to a running estate is reviewable as a diff rather than reconstructable from memory.
Guest-level backups run nightly with retention, and a restore has been performed end to end. An untested backup is a belief rather than a backup, and the distinction is worth one sentence on a page like this.
Where your subscribers' data lives, and who touches it
On a hosted platform the vendor holds the subscriber records and you receive an export. That arrangement makes them a processor of your users' personal data, and every question a regulator asks you, you then have to ask them.
This deployment model inverts that. The database runs on your estate — your hardware, or your own cloud account — so subscriber records, payment references and viewing history sit inside your perimeter and under your legal control. Data residency is therefore not a feature to enable; it is a consequence of where you chose to put the machines.
Our access is what an engagement needs and no more, it is agreed in writing, and it is revocable by you because the credentials are issued on your estate. That is a materially different relationship from one where revoking a vendor's access would stop your own service working.
Payment is the clearest illustration. Card details are entered on the gateway's own hosted page, never on a surface this platform controls, and what is stored here is a transaction reference. That is why PCI-DSS scope sits with the gateway rather than with us, and it is also why the merchant account has to be yours.
The questions a security reviewer asks
Are you ISO 27001 or SOC 2 certified?
No, to both. No certification body has assessed us and no audit observation period has begun. If your procurement process requires either as a hard gate, we do not clear it today and it is better to know that now.
Has anyone tested this from outside?
No third-party penetration test has been commissioned and none is on file. We would rather write that than describe internal review as though it were independent assurance.
Where does subscriber data live?
On your estate — your hardware, or your own cloud account — because that is what the deployment model means. It does not pass through infrastructure we operate on your behalf, which is what makes residency a consequence of your architecture rather than a setting you have to trust us about.
What happens to our data if we stop working with you?
Nothing moves, because it was never anywhere else. The database, the origin and the keys are already inside your perimeter, and the estate keeps running. That is covered in full on the ownership page.
Do you have cyber insurance or an incident response plan?
Neither has been formalised and this page will not imply otherwise. Incident handling today is the escalation path published on the service levels page — reachable 24/7, three steps, ending at a named person. A written IR plan with defined roles is honest scope for an engagement and is not something we hold today.
Why should we trust a vendor with no certifications?
On evidence rather than on assurance. The service is reachable, the architecture is published with its trade-offs, the capability list names what is missing, the performance figures state their measurement window, and the deployment leaves the data and the keys with you. None of that requires trusting us; all of it is checkable. If your risk process needs an auditor's signature instead, that is a legitimate requirement and we do not meet it yet.
Send us your security questionnaire
Most buyers have one. Send it and you get it back completed, with every question we cannot answer marked as unanswered rather than filled in optimistically.