Connect obligations, controls and evidence.

An obligation describes a requirement the organisation has determined applies within a defined scope. A risk describes uncertainty that can affect objectives. A control is an activity or mechanism intended to address a requirement or risk. Evidence supports an assessment of what was designed or what actually happened.

These records are related, but they are not interchangeable. A policy stating that access must be reviewed does not demonstrate that a review took place. A screenshot of a setting may support a specific point-in-time observation without establishing performance over a whole period.

Start with the source and applicability of the requirement. Record the interpretation and have the appropriate owner review it. Connect the selected controls and explain how they respond. Where a requirement needs several controls, make that relationship visible.

For each test, define what is being assessed, the population or sample, the period and the criteria. Link the evidence used, the conclusion reached and any limitations. A reviewer should be able to follow the reasoning without reconstructing it from separate inboxes.

1. Requirement: access should reflect approved responsibilities.
2. Control: the designated owner reviews the agreed account population on a defined schedule.
3. Test: the reviewer inspects completion, decisions and the handling of identified changes.
4. Evidence: the review record and the relevant action records support the assessment.
5. Finding: an unresolved access exception is recorded with its scope and consequence.
6. Action: an accountable owner resolves the issue or follows the appropriate exception process.

This is a process illustration, not a statement of a particular legal or certification requirement.

Before requesting evidence, describe the question the assessment is meant to answer. Identify the systems, business units, time period and activities in scope. If sampling is used, record how the sample was selected and what the conclusion can reasonably cover. These choices shape the evidence request and the eventual result.

A point-in-time inspection and a review of repeated performance answer different questions. A configuration capture may demonstrate what a setting looked like on a date. A record of completed reviews may help assess how a recurring process operated during a period. Keep the assessment claim aligned with the information actually examined.

Ask reviewers to record limitations in clear language. A missing record, an unavailable source and an observed deficiency deserve distinct treatment. When a conclusion is shared more widely, include enough context for its audience to understand what was assessed and what remains unresolved.

Define how evidence is named, linked and accessed. The record should identify its source, relevant period and the assessment it supports. Avoid creating unnecessary copies of sensitive files when a controlled reference meets the review need. Confirm that the reviewer can access the reference for the required period.

Where a document changes, decide whether the assessment needs a retained version or another way to preserve what was reviewed. The answer depends on the organisation’s evidence and retention requirements. The important design choice is preserving the basis of a past conclusion while keeping current records clear.

Review the relationships when an obligation, control or system changes. A copied mapping may no longer describe the current process. Assign an owner to consider which assessments and actions are affected, and record the decision. Traceability is maintained through these reviews as well as through the original links.

A finding needs enough detail for its owner to act: the observed condition, the evidence behind it, the scope and the decision required. An action then describes the intended resolution, the responsible role and how completion will be checked. Keep a proposed action separate from the reviewer’s conclusion that it resolved the issue.

Illustrative example: an access review identifies an account that should be removed. The action records who will make the change and where completion evidence will appear. The reviewer checks the resulting access state before closing the action. If the organisation accepts an exception, that decision follows its assigned authority and recorded conditions.

Use a walkthrough to check that the full chain can be followed in both directions. Start with a report conclusion and trace it back to the evidence, control and requirement. Then start with a changed requirement and identify the work that may need review. This is a practical acceptance exercise for a GRC implementation scope.

A summary should distinguish missing evidence, overdue work, an assessed deficiency and an accepted exception. Combining these into a single status can hide the action a team needs to take.

Start reporting from the reviewed records and disclose the scope behind the result. A useful dashboard makes the conclusion traceable and directs attention to a decision. Explore Aliph Risk & Compliance or use the workflow scoping guide to prepare an implementation.