There are two moments where a compliance platform quietly loses an enterprise. The first is the sign-in screen, when an administrator realises every one of their staff is about to get another password to forget. The second is the day after go-live, when someone in HR discovers the plan for keeping the human resources information system (HRIS) current is to hand-copy training records out of one tool and into another.
Both are avoidable, and both are integration problems, not compliance problems. So we solved them as integration problems.
Sign in with the identity you already have
The platform supports enterprise single sign-on (SSO) on a per-organisation basis, over standard OpenID Connect (OIDC) — the same protocol the rest of the corporate world already speaks. An organisation points us at its own identity provider (IdP), we perform OIDC discovery against it, and from then on staff sign in through the identity they already have. No new password, no separate account for someone to deprovision when a person leaves, no shadow directory drifting out of sync with the real one.
The important word is standard. We didn’t invent a handshake. OIDC discovery means we read the organisation’s published configuration and wire ourselves to it, rather than asking an administrator to paste a dozen endpoints into a form and hope they got them right. The organisation’s IdP stays the source of truth for who is who; we are just another application it grants a session to.
One organisation, one front door
SSO is only clean if the boundary it signs you into is the right one, and “the right one” is not the same for every kind of organisation. So sign-in behaviour adapts to organisation type. A government-type organisation signs in at its own level — its identity, its front door, its data. A multi-site enterprise signs in at the parent-organisation level, so a workforce spread across sites lands inside one coherent tenant instead of a scatter of disconnected logins that happen to share a brand.
That distinction sounds like a detail. It isn’t. It’s the difference between an enterprise seeing its whole workforce as one picture and seeing it as a filing cabinet of unrelated accounts. The sign-in decides the shape of everything that comes after it.
The part that has to be right before any of it ships
An identity feature is only worth having if you’d trust it, and trust here is not a slogan — it’s a couple of specific, unglamorous pieces of hardening that have to sit underneath before the feature is allowed anywhere near production.
First, secrets. Connecting to an organisation’s IdP means holding a client secret on its behalf. Those identity-provider client secrets are encrypted at rest — they never sit in the clear in the store.
Second, the discovery request itself. The moment your platform will fetch a URL that an organisation supplied — a discovery document, an issuer address — you have handed a potential attacker a request your servers will make for them. That is the classic setup for server-side request forgery (SSRF): coax the server into calling an address it shouldn’t, like an internal service or a cloud provider’s metadata endpoint, and let it leak what it finds. So every outbound discovery and issuer URL is validated against a guard before any request is made. The guard blocks internal and private network addresses and cloud metadata endpoints outright. A configuration that resolves somewhere it has no business reaching never gets dialled.
This is defensive engineering, not an external certification — the honest framing is that we closed off a well-known class of attack that any URL-fetching feature has to close off, and we did it before shipping the feature, not after someone reported it.
A read-only door for machines
SSO fixes the human sign-in. The second lost moment — the HRIS that goes stale — is a machine problem, and it needs a machine door.
So the platform exposes a read-only, machine-to-machine API. It authenticates with OAuth2 bearer tokens rather than browser cookies, because the thing on the other end is not a person with a browser — it’s an organisation’s HRIS, its governance dashboard, its analytics job — and it needs to authenticate as a system, on a schedule it controls, without a human in the loop.
The access is deliberately narrow in two directions. It is read-only: this door hands out compliance data, it does not accept writes. And it is scoped. Rather than a single all-or-nothing key, credentials carry granular read-only scopes covering distinct areas — compliance status, employees, training records, and audit information among them — so an organisation grants a reporting job exactly the reach it needs and nothing more. A dashboard that only needs compliance percentages never has to be trusted with the audit trail.
The result is that keeping the HRIS current stops being a copy-paste chore and becomes a scheduled pull. The system of record is Lattice Look; the organisation’s own systems reconcile against it on their own clock. This is the same connected data the platform wires together internally through its multi-tier interoperability layer, now readable from outside the walls by the systems that have a legitimate reason to read it.
One credential, one organisation
A read API is a liability the instant a credential can reach further than it should. So each integration credential is bound to a single organisation and can only ever read that organisation’s data. A key issued to one organisation cannot reach another’s — not by guessing an identifier, not by widening a scope, not by any request it can construct.
That isn’t a filter the API layer is trusted to remember to apply. The binding travels with the credential itself: its organisation is the whole world it is allowed to know exists, and there is no request shape that lets it ask about anyone else’s.
How this connects
These two features are the outward-facing edges of the same idea the rest of the platform is built on. SSO over OIDC lets an enterprise bring its own identity instead of minting a new one. The read-only, scoped API lets an enterprise’s other systems pull compliance data on their own schedule instead of re-keying it. And underneath both sit the same non-negotiables: an integration credential bound to a single organisation that can only ever read that organisation’s data — the outward face of the isolation the database enforces for every tenant — secrets encrypted at rest, outbound requests fenced against SSRF, and the whole thing running under the Australian data sovereignty guarantees an enterprise buyer is going to ask about on the first call.
An enterprise doesn’t want a new island. It wants a platform that plugs into the stack it already runs — signs its people in with the identity they already have, and feeds its systems the data they already need. That’s the door we built, on both sides.