Security

In transit. All connections to our websites, the account portal, the terminal session layer and the file transfer endpoints require TLS 1.2 or higher, with TLS 1.3 preferred and modern cipher suites only. Plaintext HTTP redirects to HTTPS, and HTTP Strict Transport Security is enabled.

Administrative access to hosts is over SSH with key-based authentication. Password authentication for shell access is disabled. We do not expose unencrypted terminal protocols to the internet — if your users reach the system over a terminal today, that session is tunnelled inside TLS or SSH by the time it leaves your network.

At rest. Every volume holding customer programs, data files, backups or logs is encrypted with AES-256 using our infrastructure provider's managed key service. Keys are held in the provider's key management service, rotated on the provider's schedule, and never checked into source control or stored on a workstation.

Backups are encrypted with their own keys, separate from the live volumes, and stored in a separate account boundary.

Honest limit. The Runtime must read your data files in cleartext to execute your programs against them — that is what an interpreter does. Encryption at rest protects the storage layer; it cannot protect against someone with legitimate execution access inside your environment. That is why sections 4, 5 and 6 matter more than this one. Any vendor telling you that at-rest encryption solves this problem has not thought about it.

One environment per customer. Each customer gets their own compute instance or instances, their own storage volumes and their own network segment. We do not run multiple customers' programs inside one shared application process, and we do not put multiple customers' files on one shared filesystem.

The Service is cloud-only — every environment runs on our infrastructure, operated by us. There is no self-hosted edition, which means there is no version of this page where a control is somebody else's job. Isolation, access control, backups and recovery are ours to get right, and ours to answer for.

There is no shared database that contains more than one customer's business data. There is no multi-tenant table with a customer identifier column that a missing WHERE clause could leak across. The isolation is at the infrastructure boundary, not in application logic — which means a bug in our code cannot hand your customer master to somebody else.

Network. Environments have no route to each other. Security groups deny by default, and only the ports required for your sessions and our administrative access are open. Nothing in your environment can initiate a connection to another tenant's environment because no path exists.

Operating system. Your Runtime processes run under a dedicated, non-privileged OS account scoped to your data directories. The Runtime executes Business Basic programs; it is not a shell. Its file and process operations are confined to the paths your environment owns.

Honest note on architecture. Today each user session is a separate process, which is heavier than it needs to be but has a security property we like: sessions do not share address space. The multi-user daemon that replaces this is landing now, and it keeps per-session privilege separation. When it ships, this section will be updated to describe what actually runs, not what we planned.

Non-production environments never contain live customer data unless you explicitly ask us to mirror your production files for a parallel run — and where we do that, the mirror is provisioned inside your environment boundary, under the same isolation and the same encryption as production. It is never staged in a shared or internal workspace of ours.

Named accounts only. Every member of our team has an individual identity. There are no shared administrative logins and no shared SSH keys. Multi-factor authentication is mandatory on every account that can reach production, on our identity provider, our source control and our cloud console.

Least privilege. Production access is granted by role, limited to the people whose job requires it, and reviewed quarterly. Engineers who do not operate the hosted service do not have production credentials. Sales and finance never do.

Path. Administrative access to customer environments goes through an authenticated bastion. Sessions are logged with the identity, the environment, the time and the commands run. Direct access from personal devices or from outside that path is not permitted.

Break-glass. There is one emergency credential per environment, held in a managed secret store, retrievable only with a second person's approval. Its use raises an alert to the whole team and requires a written explanation within 24 hours. It has never been used silently and it cannot be.

Offboarding. Access is revoked on the last working day, as a checklist item that is signed off, not as an intention. Keys and tokens that person held are rotated.

Customer-side access. You control your own users. We support individual accounts, and we will help you turn off the shared logins your current system has probably accumulated. We will not create an account in your environment for a person you have not authorized, no matter who asks or how urgent they say it is.

Who. A named group of engineers on the hosted-service team. It is a small group and we will tell you its size and its names under NDA if you ask during evaluation. Nobody outside it can reach a customer environment.

When. Only for one of these four reasons:

• Provisioning and migration you asked for — moving your programs and files, running the parallel-run comparison, cutting you over.
• A support request you opened — and only into the area of the system your request concerns.
• An incident affecting the availability or integrity of your environment, where we have to act to keep you running.
• Legal compulsion — a valid subpoena or court order, where we will notify you first and give you the chance to challenge it, unless we are legally prohibited from telling you.

Never for. Product development, market research, competitive analysis, model training, marketing, curiosity, or a demo. Those are contractual prohibitions in Terms section 9.3, not just policy on a page.

Logged. Every administrative session against your environment is logged with who, when, and what. We will provide you with that access log on request, for any period in the last 13 months. Most vendors will not do this. Ask us for it during your evaluation and see whether we deliver.

Where we can, we look at less. When we debug, we work from error output, program source and record structure before we look at record contents. We do not copy production data to a workstation, and we do not paste it into third-party tools.

Honest limit. An engineer with root on the host running your environment can, in principle, read anything on it. That is true of every hosting arrangement that has ever existed, including your closet. What differs is how few people that is, whether it is logged, whether they are contractually bound, and whether the vendor will tell you the truth about it. Our answers: a handful, yes, yes, and this page.

Schedule. A full encrypted snapshot of each customer environment nightly, plus a snapshot immediately before any change we make to your environment — a Runtime upgrade, an OS patch, a migration step.

Retention. Nightly snapshots are kept for 30 days. One snapshot per week is promoted and kept for 90 days. Backups taken before a change are kept for 30 days after that change.

Separation. Backups live in a separate storage account with separate credentials and their own encryption keys, so that compromise of a production host does not by itself give an attacker the ability to destroy your history.

Restore testing. We perform a full restore of a representative environment at least quarterly and verify that the restored system starts, signs on, and reads its files. An untested backup is a rumour; we treat it as one.

Your copy. Under Terms section 16.4 you can ask for a complete copy of your programs and data files at any time, up to four times a year, at no charge, delivered within 10 business days — in their native on-disk format, never converted or re-encoded into something only we can read. Keep your own copy. We would rather you had one than trusted ours.

Deletion of customer content follows the schedule in Terms section 15: gone from live systems within 30 days of the export window closing, and aged out of backups within 90 days of that.

Objectives. For a total loss of an environment, our current targets are a recovery point of 24 hours (the last nightly snapshot) and a recovery time of 8 hours to a working, signed-on system in another availability zone.

How. Environments are defined in infrastructure-as-code and rebuilt from that definition plus the latest snapshot. We do not rebuild from anyone's memory or from a runbook that was accurate last year.

Honest note. Those are targets we have measured in exercise, not a contractual SLA. During pre-GA we do not run hot standbys, so a zone failure means a restore, not a failover. If your business needs a tighter recovery point or a warm standby, we can build it — it is a paid option, it goes in your Order with numbers attached, and we will not pretend it is included when it is not.

Company continuity. The Runtime also runs Unique Photo's own operations. Our incentive to keep it recoverable is not contractual, it is that our warehouse stops shipping too.

If we ever wind down the Service, Terms section 16.5 commits us to 180 days' notice, continued operation through that period, and free transition assistance.

The free report asks for an archive of your programs only. Do not include data files. If we find data files in an upload, we delete them and tell you.

Transport and storage. Uploaded over TLS, written straight to an encrypted object store in a dedicated bucket with no public access, keyed to your request. Never to a laptop, never to a shared drive, never to email.

Processing. The archive is parsed by an isolated worker that performs static analysis only — we do not execute your programs. The worker has no outbound network access, so your source cannot leave it, deliberately or otherwise.

Access. Limited to the engineers producing your report and answering your questions about it. Not to sales. Not to anyone else, ever.

Deletion. The archive, the extracted source and every derivative are deleted within 90 days of upload — or immediately, on request to hello@uniquebb.com, and we will confirm in writing.

What survives. Only anonymous aggregate counts of language features — how often a verb or a file type appears across all reports — with no code, no identifiers and no company name. It is how we decide what to build next.

If you would rather not upload anything until there is paper in place, say so — we will sign a mutual NDA before you send a single file, and we will delete the archive the moment the report is delivered rather than waiting out the 90 days. Ask.

Patching cadence. Operating system and package updates are applied monthly to every host. Vulnerabilities that are rated critical, or that are known to be actively exploited, are patched within 72 hours of a fix being available — sooner if the exposure warrants it.

Dependencies. Automated dependency and container scanning runs on every build. A build with a known critical vulnerability in a runtime dependency does not ship. Base images are rebuilt at least weekly so that patched packages actually reach production.

Surface. Environments expose only the ports required to serve your sessions. Management interfaces are not internet-facing. Unused services are removed from the image rather than firewalled off.

Change windows. Patches that require a restart of your environment are scheduled with you. We do not bounce a distributor's ERP at 2pm on a Tuesday because a scanner turned amber.

Honest note. We do not currently run a paid bug bounty. We do read and act on every report sent to security@uniquebb.com — see section 15.

We maintain a written incident response plan with defined roles: an incident lead who runs the response, a communications owner who talks to affected customers, and a scribe who keeps the timeline. The plan is exercised, not filed.

Sequence. Detect, contain, preserve evidence, eradicate, recover, notify, review. Containment does not wait for a full diagnosis.

Notification — the commitment. If we confirm a security incident that affects your customer content or your personal data, we will notify you within 72 hours of confirming it. Not 72 hours after we finish investigating; 72 hours after we know you are affected.

That first notification will tell you what happened as far as we understand it, what data and which systems are involved, what we have done to contain it, what we are doing next, and what we recommend you do. If a detail is still unknown, we will say it is unknown rather than leave it out.

Post-incident report in writing within 10 business days of resolution: root cause, full timeline, impact, and the specific changes we are making so it does not recur. You may share it with your auditors and your insurer.

Where the law requires notification to a regulator or to individuals, we support you in meeting your obligations as controller, and we meet ours. See Privacy, section 12.

Review. Every change to the Runtime or the platform goes through version control and peer review. There is no direct commit to the production branch, and no editing files on a live server as a normal practice.

Environments. Development, staging and production are separate, with separate credentials. Production data is not copied into development.

Secrets. Credentials live in a managed secret store and are injected at runtime. They are not in source control, not in build logs, and not in configuration files committed to a repository. Automated secret scanning runs on every push.

Testing. The Runtime is validated against a conformance suite derived from real production programs — arithmetic to the penny, file operations byte-for-byte, terminal behavior measured against captured output rather than guessed. Regressions are caught by that suite before a release, and the suite runs on every build.

Releases are versioned, changelogged and rolled out to our own production first. We run new Runtime builds against Unique Photo's live operations before they reach a customer. If a release is going to break something, it breaks our order entry first.

Rollback. Every environment upgrade is preceded by a snapshot and can be reverted. We keep the previous Runtime build available so a rollback is a restart, not a rebuild.

We do not operate a datacenter. Customer environments run in the facilities of a major cloud infrastructure provider, and we inherit their physical controls: staffed perimeters, badge and biometric access, video surveillance, environmental and fire suppression systems, redundant power, and audited media destruction. Those facilities hold their own independent certifications; ours are not implied by theirs, and we do not present them as ours.

Our offices. No customer data is stored on office equipment. Company laptops have full-disk encryption, automatic screen lock and remote wipe, and are enrolled in device management.

Customer content is never written to removable media. There are no USB backups of your data files anywhere in our organization.

Printed material containing customer information is not produced. If it ever is, it is cross-cut shredded.

Everyone with production access is an employee of Unique Photo, not an anonymous contractor pool, and is bound by written confidentiality obligations that survive their employment.

Background checks are performed for roles with production access, to the extent permitted by law.

Security training happens at onboarding and annually, and covers the things that actually get companies breached: phishing, credential handling, social engineering over the phone, and the pressure to skip a control because someone senior is in a hurry.

We will never ask you for your password, and we will never ask you to disable multi-factor authentication. If someone claiming to be from UBB asks either, it is not us — hang up and write to security@uniquebb.com.

Send it to security@uniquebb.com. Plain email is fine; we do not require encryption to receive a report, though we will happily move to an encrypted channel for details.

What we commit to: acknowledgement within 2 business days, an initial assessment within 5 business days, regular updates until it is closed, and credit in our release notes if you want it.

Safe harbour. If you research in good faith, stay within the scope below, do not access or modify data that is not yours, do not degrade the service for others, and give us reasonable time to fix the issue before disclosing it, we will not pursue legal action against you and we will say so in writing if you ask.

In scope: our public websites and the account portal. Out of scope: customer environments (they contain other companies' data — never test against one), denial-of-service and volumetric testing, social engineering of our staff or our customers, physical attacks, and findings that are purely the output of an automated scanner with no demonstrated impact.

Authorized testing. Any active security testing needs prior written authorisation — see the Acceptable Use Policy. Customers may test their own environment. Ask at security@uniquebb.com, tell us the window and the source addresses, and we will normally say yes within 5 business days.

We complete security questionnaires. Send yours to security@uniquebb.com and we will return it, in your format, within 10 business days. Where the honest answer is "no", the answer will be "no" — you will not get a paragraph of evasion in the comments column.

We will get on a call with your IT team, your auditor or your insurer, and we will put anything we tell you in writing so you can hold us to it.

We will sign a mutual NDA before the detailed conversation, and a data processing addendum before we touch anything of yours. See Privacy, section 4.5.

This page is reviewed at least twice a year and whenever a control materially changes. The review date is at the top. If a control described here stops being true, we change the page — we do not quietly leave it up.