> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/solution-architecture/programme/regulated-environments.md). # Operating in a regulated environment What OpenIAM genuinely provides towards a regulated organization's controls — audit trail, certification evidence, approval records, SoD detection — and what the organization must do itself, stated as ## What this is, and when you need it Where an estate operates under a quality or regulatory framework — pharmaceutical manufacture, financial services, medical devices, critical infrastructure — one sentence has to be got exactly right, and it is frequently overstated in both directions: > **The technology supports the controls and produces the evidence; the organization validates the configured process under its own quality framework.** That is the position this guide takes, and this page exists so it can be repeated accurately. Weaken it and you understate a platform that genuinely produces good evidence. Strengthen it — "OpenIAM is compliant with", "the product delivers validation" — and you have made a claim no identity platform can support, in a document that may be read by a regulator. You need this page when a compliance function asks what the platform does for them, when a sales or architecture document is being reviewed before it goes outside, or when a validation lead is working out what has to be written and by whom. ## The decision The decision here is not which product feature to use. It is **where you draw the boundary in your own documentation**, and there are three defensible positions and one that is not. | Position | What it says | Assessment | | ------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | | **The platform supports the controls and produces evidence; we validate the process** | The technology is a component of a control the organization designs, operates and qualifies | Correct. This is the position to take, and the wording above is the wording to use | | **The platform is a validated system** | The system, in its configured state, has been qualified | Only ever true of *your* installation, after *you* have qualified it. It is a statement about an instance, never about a product | | **The platform is one control among several** | Some obligations are met partly here and partly by procedure | Correct and often more honest than a single-system claim, particularly for termination and for segregation of duties | | **The platform is compliant with the regulation** | The product delivers the outcome | Not a claim anyone can support. Regulations apply to organizations and their processes, not to software | ## What the platform genuinely provides Six things, stated as what they are rather than as what an obligation might want them to be. **An audit trail of consequential actions.** Every significant operation writes an audit record carrying the actor, the principal, a timestamp, the source and client address, the action, the result, and typed references to the objects it touched — the users, roles, groups, resources, organizations and managed systems involved. It is searchable, and it can be dispatched continuously to an external destination over HTTP or syslog, which is the usual way an organization gets identity events into a monitored, retained platform. Two properties of that trail belong in any design that relies on it. **It lives in the search tier, not in the relational database** — the tables that once held it were dropped some releases ago — so a database backup that covers every schema preserves not one audit event; retention is a decision about snapshotting or exporting the search tier. And **the retention properties ship set to never prune**, which means the shipped default keeps everything. That is a helpful default and it is not a retention policy; yours has to be stated, and then implemented deliberately in one direction or the other. **Certification evidence.** A closed campaign leaves a durable record: who reviewed what, when, with the note they left, and whether the decision was made individually, in a bulk action, or automatically by an auto-certification rule. The user's details are snapshotted at launch, so a review read back years later describes the person as they were. Crucially, the record also contains **who was not reviewed and why** — excluded by scope, dropped because nothing remained to review, or held out because no reviewer could be resolved. That second half is what makes a coverage claim defensible rather than optimistic, and it exists only for campaigns launched from a preview. **Approval records.** Where access was requested, the approval engine retains the history of the request: the steps, who was asked, who decided and when. That is the record behind "who authorized this access", which is usually the first question asked about any individual grant. **Segregation-of-duties detection.** Conflicts are evaluated at the moment access is granted and again in a full-population sweep, and the result is a record of who holds which conflict. Where a conflict is permitted, the permission itself is evidence: an exemption carries its author and a comment, and a mitigating control carries a named owner, a named manager, a review frequency and effective dates. **A rehearsal mechanism.** A managed system can be put into simulation, where OpenIAM builds each provisioning operation exactly as it would for a real send and stores it for review instead of dispatching it. For a validated change this is the closest thing to a dry run that exists — the actual outbound attribute set, for real people, before the target receives anything. Part 5, *Planning a wave migration*, treats it as the primary validation activity for a change of governance owner, and the same logic applies to any change with a wide blast radius. **An independent comparison against the target.** Reconciliation reads a managed system's own state and compares it with OpenIAM's record. This matters more than it looks: almost every other artefact on this list records what OpenIAM *asked* a system to do. Reconciliation is the one that establishes what the system actually holds, and an evidence pack that never leaves OpenIAM's own record has a gap where its most important assertion should be. ## What the organization must do itself Everything that turns those artefacts into a control. This list is not a disclaimer; it is the work, and it should be resourced in the plan. **Decide which processes are in scope, and what each control is meant to achieve.** The platform does not know which of your applications are regulated, which populations matter, or what your risk assessment concluded. Control design is upstream of every configuration decision in Parts 2 to 4. **Qualify the configured system, and validate the process it implements.** The specification, the test protocols, the execution, the deviations, the acceptance criteria and the sign-off are the organization's, produced under its own procedures. No product ships them, and a product that claimed to would be making your quality function's decisions for it. **Own change control over the configuration.** This is the gap most often missed. OpenIAM governs access to applications; **it does not govern changes to its own configuration through its own request and approval machinery.** A change to an approval policy, a business rule, a certification definition or an SoD classification is audited — you can see who changed what and when — but it is not itself approved by a workflow before it takes effect. Where a validated state has to be maintained, the maker-checker control over configuration is a procedural one that you operate, supported by the audit trail and by promoting reviewed configuration between environments rather than editing production directly. **Own retention and the evidence archive.** Decide how long each class of record is kept, implement it for the search tier specifically, and decide where the archive lives. If the organization's answer is a monitored external platform, the continuous export is the mechanism; if it is snapshots, that is an infrastructure task with a tested restore. **Own the periodic review of the controls themselves.** Whether the campaign cadence is still right, whether the reviewer population still makes sense, whether the SoD classifications still reflect the risk assessment. Nothing in the platform prompts this. **Own environment and supplier qualification**, and the infrastructure controls around the deployment — who can reach the database, who holds the secrets store, how the search tier is protected. Part 7 covers the shapes; the qualification of the chosen shape is yours. **Decide what happens to records at end of life.** When a platform, an application or an integration is retired, its historical approval and certification records are the evidence for everything granted under it, and they do not migrate anywhere by themselves. That is a records decision with a retention period attached, and it belongs in the programme plan. ## What we recommend **Use the boundary sentence verbatim, in both directions.** In a document that goes to a regulator and in a conversation with a sponsor who wants to hear something stronger. Consistency here is worth more than emphasis. **Write the control descriptions before configuring, and make them match what the product does.** The most common finding is not a missing capability; it is a control description that says "reviewers are reminded after seven days" or "access expires after ninety days" while the scheduled work that would do either ships disabled. Verify each sentence of a control description against actual behaviour before it is signed. **Treat the exclusion half of a certification record as part of the evidence, from the first campaign.** A coverage figure derived only from reviewed items overstates coverage, and the discrepancy is exactly what a competent auditor samples for. **Put reconciliation in the evidence pack, not just provisioning records.** The target's own state is the assertion that matters. **Decide the audit retention policy explicitly**, and implement it against the search tier. The shipped never-prune default is a good starting point and a poor answer to "what is your retention policy". **Use simulation as the rehearsal for any wide change**, and keep what it produced. It is the cheapest objective evidence available and it costs nothing to generate. The circumstance that changes this advice is a coexistence estate, where part of the population is governed by another platform. There, no single system's records are a complete answer for any period, and the evidence has to name the platform that was the write owner at the time. Part 5, *Coexisting with an incumbent IGA*, is the design that keeps that answerable. ## What OpenIAM does not do here * **The product does not deliver compliance, and no configuration of it does.** It supports controls and produces evidence; qualification and validation are the organization's. * **No validation or qualification documentation ships with the product.** There is no protocol set, no qualification pack and no pre-written control description to adopt. * **There is no electronic-signature control.** A decision — an approval, a certification outcome — is recorded as an authenticated user's action with a timestamp and an optional note. There is no fresh authentication challenge bound to the decision and no meaning-of-signature captured alongside it. * **The audit trail is not sealed or write-once.** Records carry no integrity hash or signature; their trustworthiness rests on the controls you place around the search tier, and around the export destination if you use one. * **Configuration changes are audited, not approved.** OpenIAM's own configuration is not routed through its request and approval machinery, so maker-checker over configuration is a procedure you operate. * **There is no compliance report.** No screen answers "are we compliant"; the artefacts above are inputs to an assessment somebody else performs. * **Audit retention is not managed for you.** The shipped properties prune nothing, and the audit trail is not covered by a database backup. ## Related * [Phasing a rollout](/solution-architecture/programme/phasing-a-rollout.md) — the evidence path, exercised once in phase one. * Part 4, *Designing a certification programme* — what the certification record proves, and what it omits. * Part 5, *Planning a wave migration* — validation as the unit of a governance-owner change, and simulation as its rehearsal. * *Audit export to a SIEM*, *Simulation mode* and *Promote configuration between environments* in the Administration Guide — the mechanisms behind the artefacts named here. *Applies to OpenIAM 2026.8.1. Last reviewed 7 August 2026.* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.openiam.com/solution-architecture/programme/regulated-environments.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.