midPoint for ISO 27001 access rights control A.5.18

midPoint decides whether an access grant is allowed before it reaches a target system, and the decision is recorded as part of the operation itself. When a request or lifecycle event asks for a role assignment, midPoint evaluates the policy rules that apply to that operation. Where a rule requires a human decision, midPoint starts an approval process and resolves the approvers, which can be computed from the organization model (for example, from a manager reference or a role owner) rather than hard-coded per request. For ISO/IEC 27001:2022 control A.5.18, this is the mechanism that makes the provisioning step follow the organization's rules instead of an administrator's judgment. The control text asks that access rights be provisioned in accordance with the topic-specific policy on, and rules for, access control, so the first question to answer is which operations must pass through a rule and which may bypass one.

The policy itself is the organization's responsibility. A.5.18 expects a topic-specific access control policy that states who may request which access, who must approve it, and when a grant is refused. midPoint does not write that policy for you. Your team should first produce the written rules, then translate them into midPoint policy rules, approval configuration and role assignment conditions. Review each configured rule against the policy line it implements, and keep a mapping between the two. An auditor who samples a grant will usually ask whether the rule that allowed it matches the policy in force on that date, so keep the policy version history alongside the midPoint configuration history.

A provisioning record should show four things: who requested the access, who approved it, which rule governed the decision, and evidence that the granted access matched the policy. In midPoint, the request and its outcome are held in the case and approval objects created for the operation, while the assignment itself records what was granted and the metadata of the change. Trace the link from the assignment to the case that produced it, and from the case to the approvers and the decision each one recorded. Confirm in your own midPoint version exactly which fields the approval trace stores, how long it is retained, and whether the policy rule identifier appears in the trace or must be correlated from the configuration. Do not rely on memory of field names across releases.

Plan for the cases where the trace is incomplete. Automatically applied assignments, changes made by a bulk task, and changes imported from an authoritative source may not pass through an approval at all, and the record then depends on the rule and the source event. Decide in advance which of these paths your policy permits, and test each one with a non-production identity. Also decide how approvals are handled when an approver leaves the organization or is unavailable, because a delegated or escalated approver changes who appears in the trace. These decisions belong in the design phase, because changing them later alters the evidence you already hold.

Verify the result before relying on it. Run a set of test requests that cover each rule: an approved request, a rejected request, a request that should bypass approval and a request with a computed approver that has changed. For each test, check that the assignment, the approval trace and the rule identifier agree, and that the record can be exported or retrieved in the form an auditor would request. Keep the test results as part of the control evidence. This also gives you a baseline to repeat after upgrades, since approval behavior and trace contents can change between midPoint releases.

In midPoint, an access certification campaign does not complete the removal part of A.5.18 on its own. According to the Evolveum documentation, campaigns end with remediation, the stage in which decisions to remove access are carried out. The review part of A.5.18 maps to the campaign and its reviewer decisions, while the removal part maps to remediation and to evidence that the target system changed. An auditor sampling this control will look for both, so the implementation plan should treat the campaign report and the remediation outcome as one body of evidence rather than two separate deliverables.

A campaign record that will hold up in an ISMS audit should show its scope, reviewers, decisions, timestamps and remediation outcome. Scope means which resources, roles or populations the campaign covered and the definition used to select them. Reviewers should be shown as assigned to each item, and each decision (for example approve, revoke or reduce) should be traceable to the item it concerns. Timestamps should cover campaign start, review deadlines, the decision and the closure. The remediation outcome should show, per revoked item, whether removal succeeded, failed or was skipped. Confirm with your midPoint version which of these fields the campaign report exports and whether per-item decision history is kept or only the final state.

The common gap is a reviewer who decides to revoke an entitlement while the removal is never executed or is executed without a record. Causes include a connector error on the target system, a remediation task that was not run, or a manual target system where the change happens outside midPoint. To check remediation, sample revoked items from the campaign and compare each one against the target system directly, using a read-only query of the account or group membership. Compare the remediation timestamp with the decision timestamp, and review midPoint task and audit output for failed provisioning. Confirm that each target's connector is in a support status you accept, as listed in the Evolveum connector catalog. The sampling approach here is one option, and your own procedure should be written against your environment.

Before the first campaign closes, decide who owns remediation reconciliation, how overdue decisions are escalated, and how items not decided in time are handled. Keep campaign reports and target-system verification results together so an auditor can follow a revoke decision from review to removal. Validate every campaign report in your own midPoint version, because report content can differ between releases. Ask your auditor which evidence formats they accept for this control. DeployOpen can prepare the systems, controls and evidence for this review, but the audit conclusion itself comes from an independent auditor or certification body.