Compliance
Security
Greenlight is built to slot into the compliance frameworks customer organizations already operate under. The platform’s job is to make the evidence trail trivial to assemble; the certifications themselves belong to the operating organization, since Greenlight runs entirely in the customer’s cloud and the customer is in control of the data.
What Greenlight gives you for evidence
Section titled “What Greenlight gives you for evidence”The structured audit log is the spine of the evidence story. Today, Greenlight records the events needed to support customer-led compliance reviews:
| Control area | Evidence Greenlight produces |
|---|---|
| Access control | Role assignments and revocations, with the IdP group mapping that produced them. Agent OAuth authorize and token-exchange failures (expired or replayed codes, PKCE mismatches, deactivated users) land in the same trail with a stable reason. |
| Change management | Every PR, every policy-check result, every override with reason and reviewer. |
| Data access | Per-call records for every integration call, including bound user, app, upstream, and response code. |
| Configuration management | Every policy bundle change, every integration registration, every secret rotation. |
| Incident response | Every kill, restore, and override event, with timestamps and actor identities. |
The SOC 2 view in the dashboard
Section titled “The SOC 2 view in the dashboard”Admin → Compliance lays the SOC 2 common criteria out against the Greenlight mechanism that covers each one — CC6 (logical access), CC7 (system monitoring and vulnerability detection), CC8 (change management) — and links each row to the live surface where the proof is read. Each control is marked with what it does in your organization: enforced at merge when every check behind it is set to block, reported, not blocking when any of them is set to warn or switched off, or recorded for a structural property such as every app sitting behind SSO. Greenlight’s code-scanning checks start at warn so a first deploy is never held by whatever history a repository arrived with, so those controls read as reported until you promote them — the page names which checks, and links to where you change that. Beneath the mapping, every app’s most recent deploy shows its commit, gate decision, and the pull request that authorized it.
The whole thing exports as JSON or CSV, so your compliance platform can ingest Greenlight’s slice alongside everything else it tracks.
Three things the page is careful about, because a compliance surface that overstates is worse than none:
- It reports control coverage and evidence, never that your organization is compliant or certified. That remains your auditor’s call.
- It covers the applications Greenlight governs — not your wider estate. That boundary is written into the export itself, so a file forwarded to an auditor carries it.
- A deploy whose gate decision was never recorded says exactly that, rather than being shown as passing.
- SBOMs are kept. CI produces one per build and discards it within a fortnight, so Greenlight takes its own copy when the deploy passes its gate — those stay downloadable from this page with no expiry. Where no copy exists (a deploy from before this shipped, or one whose copy failed), the page says so rather than offering a link that fails. Taking the copy can never hold up a deploy.
Full audit-log search and export, SIEM forwarding, WORM storage, and HMAC signing are coming soon — those are about the raw trail, and are separate from the SOC 2 mapping export below. Until those ship, Greenlight’s compliance value is the durable audit trail it writes inside the customer’s installation.
Framework status
Section titled “Framework status”| Framework | Status |
|---|---|
| SOC 2 Type 2 | Control coverage mapped and exportable in the dashboard (see above); formal customer-facing packet coming soon |
| HIPAA | Security Rule safeguard coverage mapped and exportable alongside SOC 2. The business-associate deploy gate is built but not yet self-serve — putting an integration in PHI scope and recording its agreement needs Shift’s help today. Also still requires the planned tamper-evident audit storage before production use |
| GDPR | Article coverage mapped and exportable alongside SOC 2. The residency deploy gate is built but not yet self-serve — marking an organization as EU-designated and recording integration residency needs Shift’s help today |
| ISO 27001 | Coming soon |
| PCI-DSS | Not in scope |
The current evidence model can support SOC 2-style change-management, access-review, and privileged-action evidence. It is not a certification claim. Customers that require HIPAA, ISO 27001, or other tamper-evident immutable retention should wait for the planned tamper-evident audit storage.
For HIPAA specifically, one control is designed to be enforced rather than only evidenced: once an integration is in PHI scope, it cannot be granted to an app until a Business Associate Agreement is recorded against it, and the agreement lapsing on its end date puts the integration back behind the gate. The check is built and runs in the deploy gate, but the dashboard has no way to put an integration in PHI scope or record an agreement yet — both are set up with Shift for now, and a self-serve surface is planned. Until an installation has something in PHI scope it stays dormant by design: no HIPAA section in the compliance view, and nothing about HIPAA anywhere in the product.
For GDPR, the equivalent differentiator is residency: an EU-designated organization may grant only integrations that have residency recorded against them. That check is also built and runs in the deploy gate, and the dashboard has no way to mark an organization as EU-designated or record residency yet — both are set up with Shift. Until an installation is designated it stays dormant by design: no GDPR section, and nothing about GDPR anywhere in the product.
One thing worth being explicit about: there is no compliance pack to enable. Greenlight has one set of deploy checks, which you tune (Manage policies), and compliance value comes from the evidence those checks and the audit trail produce — not from a framework-specific rule set switching on.
What the customer is responsible for
Section titled “What the customer is responsible for”Because Greenlight runs inside the customer’s cloud and uses the customer’s IdP, the customer organization is the controller in the data-protection sense. They retain responsibility for:
- The cloud environment’s security posture (account-level MFA, root-account hygiene, IAM).
- The IdP’s security posture (SSO configuration, MFA enforcement, conditional access).
- The integrations they choose to grant and the credentials they provide for them.
- The retention posture and evidence collection process for the audit log.
- End-user data handling — Greenlight does not see or process data passing through the data broker, beyond the metadata captured in audit.
This division is the same as any in-cloud platform: the cloud provider is responsible for the substrate; the customer is responsible for what they build on top of it. Greenlight sits in the customer’s column.
Coming soon
Section titled “Coming soon”The SOC 2 control matrix, the HIPAA Security Rule safeguard mapping, and the GDPR article mapping all ship today, each with its own JSON/CSV export (see above). An ISO 27001 mapping, and a prepared security-review packet, are still to come. Contact early-access@greenlightbyshift.com for the current one.