> 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/governance/certification-programme.md). # Designing a certification programme Designing an access certification programme — which campaign types to run, on what cadence, over what scope, resolved to which reviewers, and what the resulting evidence has to prove to somebody who w ## What this is, and when you need it A certification programme is not a campaign. It is a standing commitment: **these populations and these applications are reviewed on this cadence, by these people, and here is what the record proves.** The commitment is made to an audit or compliance function, usually before anything is configured, and it is very hard to renegotiate downwards once made. This page is the four decisions behind that commitment — type, cadence, scope and reviewer — plus the one that is usually left implicit and matters most, which is what the evidence has to prove. Creating a campaign is an Administration Guide task; *Plan and scope a campaign* covers it well and this page does not repeat it. You need this page when you are drafting the governance section of a design, when you are answering an audit questionnaire about review frequency, or when a first campaign has come back with a ninety-five per cent approval rate and somebody has quietly noticed that this means nothing. ## The decision | Decision | The options | What it turns on | | ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | | **Type** | Review a population and see all its access; or review an application and see everyone who holds its entitlements. Either can be narrowed to risky grants only | Which axis the obligation runs along, and which one you can defend to the person who asked for the review | | **Cadence** | Monthly, quarterly, semi-annual or annual for a scheduled certification; on demand for anything else; continuous only in the sense of a risk-filtered campaign on a schedule | How much reviewer attention exists, and what the obligation actually says. Cadence is bounded by reviewer capacity, not by the product | | **Scope** | One department, one application, one population, one risk band — or everything | How many decisions each reviewer will face. This is the number that decides whether the campaign produces judgement or rubber-stamping | | **Reviewer** | The person's manager, the entitlement's owner or admin, the application's owner or admin, an organizational certifier, a named person, a group, or the account's own owner | Whether the catalogue actually carries owners, and who can plausibly say yes or no to this particular item | ### Choosing the type The two types answer two different questions and are not degrees of thoroughness. **Review the person** when the obligation is per person: a departmental review, a contractor review, everyone reporting to a named manager. The reviewer sees one individual and everything they hold, which is the only view that catches accumulated access from a career of transfers. It is also the view a manager can actually reason about, because they know the person. **Review the application** when the obligation is per system: a financial system in regulatory scope, a review demanded by an application owner. The reviewer sees one entitlement and everyone who holds it, which is the only view that catches "why do four hundred people have this?". It needs an owner who knows the entitlement, which the person's manager usually does not. Most programmes need both: a periodic per-person review for breadth, and a per-application review for the systems that are actually in scope for something. **Risk is not a third type — it is a filter on either of these two.** A campaign can be narrowed to the access grants scoring at or above a threshold, which is how you cover a population you cannot afford to review in full every quarter. Because it is a filter rather than a type, "review the risky access in Finance" is a per-person review with a threshold set, and the same threshold can just as well narrow a per-application review. It reads from the risk store, so it is worth nothing until risk scoring is configured and the ratings on the catalogue are real. Adding it is a maturity step, not a starting point. ### Choosing the cadence The shipped scheduling granularity is monthly, quarterly, semi-annual and annual. There is no weekly or daily certification, and "continuous certification" in OpenIAM means a risk-filtered campaign running on a schedule, not a stream. Two facts should shape the cadence more than the obligation's wording does. **A scheduled certification does not launch a campaign by itself.** The schedule produces a preview — a computed, browsable snapshot of exactly who would be reviewed and what they would be asked — and a human promotes that preview into a live campaign. There is no unattended launch. That is a good design and it has a programme consequence: **every cadence you commit to needs a named person who promotes it**, and a quarterly commitment with nobody rostered to promote the preview is a quarterly commitment that quietly becomes annual. **Cadence multiplies with scope.** A quarterly campaign over the whole population is four times the reviewer load of an annual one, and reviewer load is the binding constraint on quality. Where the obligation permits, a narrow quarterly review of the sensitive population plus an annual review of everyone is a better programme than a quarterly review of everyone that nobody reads. ### Choosing the scope Scope is where certification programmes fail, and the failure is always the same: too many items per reviewer, so the reviewer bulk-approves, so the campaign produces an audit trail of decisions nobody made. The product gives you the number in advance. A preview computes the campaign without writing anything, without notifying anyone and without starting any workflow, and reports how many review items it would create, how many users and items it excluded and why, and how many users it could not resolve a reviewer for. **Divide the item count by the reviewer count before every launch.** If the answer is in the hundreds per person, the scope is wrong, and narrowing it is cheaper than explaining the result. Two other scope decisions belong in the design rather than in each campaign. **What is deliberately out of scope**, and why — memberships still awaiting manual fulfilment, entitlements not yet effective, access granted by a mechanism the review does not govern. And **what a lapsed or future-dated membership means to this review**, because those are excluded by default and an auditor who assumes full coverage will ask. ### Choosing the reviewer The reviewer options are wide, and the choice is a judgement about who can actually decide. A **manager** knows the person and rarely knows the entitlement. An **entitlement or application owner** knows the entitlement and rarely knows the person. That asymmetry is the argument for multi-step reviews: the manager attests that the person still needs the job, the owner attests that the entitlement still means what it says. It is also the argument against asking either one to do the other's job. Two structural facts constrain the choice more than preference does. **Reviewer resolution is a data dependency, and failure is silent to the reviewer.** If a step resolves to the supervisor and a user has none, or to the entitlement owner and the role has none, that user or item is held out of the campaign and recorded as an exclusion. Nobody is asked and nothing appears to go wrong. This is why the owner requirement in [Designing the role model](/solution-architecture/governance/role-model.md) is load-bearing: an unowned catalogue produces campaigns that quietly review less than they claim. **Reminders, escalation and the on-expiry action depend on scheduled work that ships disabled.** Two shipped batch tasks drive approver reminders and the detection of an expired review step, and both ship switched off. A programme whose control description says "reviewers are reminded after seven days and the item escalates after fourteen" is describing behaviour that does not happen until somebody enables them. Decide this in the design, and verify it before the first campaign rather than after. ## What the evidence must prove This is the decision most often left out of a design, and the one an auditor actually tests. Work backwards from the questions that will be asked. **Who decided, and when.** Every decision is recorded against the reviewer who made it, with a date and an optional note, and the record survives the campaign closing. That much is straightforward. **What they were looking at.** A campaign snapshots the user's details at launch, so a review read back two years later still describes the person as they were, not as they are now. What the reviewer could *not* see matters too: metadata attached to a role is not shown in the review detail, so anything a decision depended on has to be in the role's name and description. This is a design constraint on the catalogue, discovered late by people who did not read it here. **How the decision was made.** Each decision records whether it was made individually, as part of a bulk action, or automatically by an auto-certification rule. Auditors ask which items were waved through in bulk, and the record answers. That is a reason to decide the bulk-approval and auto-certification policy at design time: **an auto-certified item is a recorded policy outcome, not a human attestation**, and if your control description says a human reviewed every item then auto-certification contradicts it. Where you do use it, the choice of whether auto-certified items are hidden from the reviewer or shown to them as pre-approved is a transparency decision worth making deliberately. **Who was not reviewed, and why.** This is the one that catches programmes out. A campaign's record has two halves: the items that were reviewed, and the users and items that never entered the campaign — excluded by a scope filter, dropped because nothing was left to review after filtering, or held out because no reviewer could be resolved. **A coverage report built only from reviewed items overstates coverage**, sometimes substantially, and the discrepancy is exactly what a competent auditor samples for. Design the report as the union of both halves from the start. **What happened next.** A revoke decision is an instruction, not an outcome. The evidence chain has to continue into provisioning: the request that was raised, the connector reply, and the state of the account in the target. A campaign that closes with revocations that never reached the target system is worse than no campaign, because it produces confident evidence of a control that did not operate. **What happens to an item nobody decided.** The shipped default on expiry is to do nothing, which leaves the item un-actioned and the access in place. The alternatives revoke everything outstanding, or revoke only what a reviewer had already marked. This is a policy choice with a real business consequence and it should be made by the control owner, not inherited. ## What we recommend **Run two campaign types, not one.** A per-person review for breadth and a per-application review for the systems in regulatory scope. Add the risk filter to either of them once risk ratings on the catalogue are real. **Set cadence from reviewer capacity, then check it against the obligation** — not the other way round. A narrow quarterly review plus a broad annual one beats a broad quarterly one that is bulk-approved. **Never launch without reading the preview's numbers.** Items per reviewer, exclusions as a proportion of the population, and unresolved reviewers. All three are free to obtain and all three change decisions. **Treat unresolved reviewers as a defect, not a campaign outcome.** They are missing owners and missing supervisors, and they are cheaper to fix before a launch than to explain after one. **Decide the auto-certification and bulk-approval policy in the design**, and make sure the control description you give an auditor matches it. **Design the coverage report as the union of reviewed and excluded**, from the first campaign. Retrofitting it after an audit finding is a bad quarter. **Make the first campaign deliberately small.** Its purpose is to prove the reviewer resolution, the notifications, the evidence and the revoke path end to end — not to demonstrate coverage. The circumstance that changes this advice is a first campaign in an estate whose catalogue has no owners yet. There, a per-person review with the manager as reviewer is the only type that will resolve, and the programme's first job is to use it to establish ownership rather than to attest to anything. ## What OpenIAM does not do here * **A scheduled certification does not launch a campaign.** It produces a preview that a person must promote. There is no unattended campaign launch. * **Reminders, escalation and expiry detection depend on two shipped batch tasks that ship disabled.** Configured reminder cadences do nothing until they are enabled. * **An unresolvable reviewer removes the user or the item from the campaign silently.** The reviewer is never told, and only the exclusion record shows it happened. * **Role metadata attributes are not rendered to a reviewer.** Anything a decision depends on must be in the name or the description. * **A campaign launched without a preview keeps no exclusion record.** You can never afterwards show who was left out and why, which makes it unsuitable for anything you have to evidence. * **Editing a certification definition does not change a running campaign.** The settings that matter are copied at launch; a change applies to the next one. * **There is no cross-campaign coverage view.** Proving that every in-scope identity was reviewed within a period is a report you assemble across campaigns. ## Related * [Designing the role model](/solution-architecture/governance/role-model.md) — owners and descriptions, which decide whether a campaign resolves and whether a reviewer can decide. * [Designing a segregation-of-duties programme](/solution-architecture/governance/sod-programme.md) — the conflicts a reviewer sees attached to an item. * *Plan and scope a campaign*, *Configure the review workflow* and *Campaign history and evidence* in the Administration Guide — the mechanism, configured. * Part 8, *Operating in a regulated environment* — what this evidence does and does not establish. *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/governance/certification-programme.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.