ServiceNow GRC, policy and audit evidence with clear ownership

Turning an obligation into a control statement a reviewer can test

Policies state what an organization intends. A control statement says who does what, how often, on which population and with what expected result. The gap between the two is where many GRC programs lose their way. A policy that requires access to be reviewed regularly does not tell a reviewer whether the review happened last quarter, who performed it or what they checked. The table shows how one obligation can be rewritten into a statement a reviewer can test.

The statement in the right-hand column is an example of the form, not a model for every organization’s obligations. The test is whether someone who had no part in writing it could check whether it was performed.

Evidence a reviewer can use without a follow-up conversation

Evidence is often collected as a file and attached to a record. Storage is not the same as review. An export of a user list is weak evidence on its own. An export that carries the date it was taken, the filter applied, the decision recorded against each row and the name of the reviewer is evidence that can be tested.

The scope should be stated as clearly as the result. If a control covered four of five production systems, the record should say so, and the gap should appear as a finding rather than being left for the reviewer to discover. Evidence that hides its scope tends to be challenged later, and the challenge can be more expensive than the gap would have been.

Retention is part of evidence design too. A record should be kept for as long as the obligation requires and no longer, and the period belongs in the control statement rather than in the memory of whoever holds the file. Where an outside obligation sets the period, the control owner should record which obligation it is, not only the number of years. A retention rule that nobody can trace to its source is hard to defend when a reviewer asks why a record was destroyed or why it was kept.

Keeping sensitive data out of the evidence store

Evidence packs drift towards over-collection. A reviewer asks for the list of staff who did not complete a training module, and the pack ends up holding full personnel records. The control should be designed to produce the smallest record that answers the question: a count, an identifier that can be traced in the source system, or a conclusion with the relevant exception attached. Where a reviewer does need the detail, access to it should be limited and the reason for access recorded.

When a repeated exception shows the control was designed wrongly

An exception is a decision, not permission to stop thinking about the control. When the same exception is renewed several times without a change in circumstances, the control is probably unrealiztic for the way the work is actually done, or the process that owns it has no clear owner. The reviewer should be able to ask two questions of any renewed exception: what would have to be true for the exception to end, and who has the authority to end it. If the answers are unclear, the next decision is about the control’s design, not about the exception.

Linking findings to remediation and to a verified close

A finding should lead to a remediation task with an owner, a due date and a method of confirming completion. Closing the task does not close the risk. The reviewer decides whether the control now operates as written, whether the new evidence is sufficient and whether any residual risk remains. Many programs mark a finding closed when the ticket is resolved, then discover at the next review that the control was never redesigned. The risk assessment and control testing page covers ServiceNow control testing and its evidence trail.

What a first review should produce

For an organization that already has policies and a register, the first useful output is a short list: obligations with no testable control, controls with no named reviewer, and exceptions with no expiry. That list is often more valuable than a full rebuild of the register, because it shows where effort will reduce the most risk. The security, risk and governance page covers ServiceNow control ownership for security and risk.

Is a control statement the same as a procedure?

No. A procedure explains how a task is performed. A control statement says what must be true at the end and how that will be shown. The procedure can change without changing the control, and that separation is what makes the control reviewable.

Who should review the evidence for a control whose performer is senior?

Someone who reports through a different line from the performer, or who sits outside the function being reviewed. Where that is not possible, the review should say so and record the compensating step.

How much evidence is enough?

Enough to let a reviewer reach the same conclusion as the performer without calling them to explain the record. If the reviewer has to ask questions to understand it, the evidence is not yet sufficient.

Should every policy statement become a control?

No. Some statements set direction and are not meant to be tested directly. Others describe a duty that a control should cover. Sorting the two is part of the first review.

Starting a GRC evidence conversation

A useful first step is to settle which obligations to test first, who owns each control and which evidence would convince a reviewer that the control operates as the policy intends. Questions on that can be sent through the contact page.