Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 5 of 5

Testing GRC changes

9 min

Listen to this lesson

0:00 / 5:53

Access Control is itself a system with configuration, and a change to it can weaken every control it supports. A workflow rule that routes high-risk requests past the risk owner, a function missing a new Fiori app, a connector pointing at the wrong system, or a log collection job that stopped: each one silently turns a control off. Changes to GRC configuration need testing with the same discipline as changes to business processes.

What to test, by area

AreaExample changeTests that prove it
Rule setNew Fiori app added as an action to supplier maintenanceAnalyze a test role containing the app with a payment role: P001 must be reported
Workflow and BRFplus rulesNew path for high-risk finance requestsSubmit low-risk and high-risk requests; each takes the expected path and reaches the right approvers
ProvisioningNew connector settings for CMQApproved request creates or changes exactly the requested user and roles in the right system and client
Emergency accessNew finance support firefighter IDCheck-out works only for listed firefighters; session actions appear in the log; log reaches the controller
Access reviewsNew reviewer determination ruleReview requests go to the right managers; removals are provisioned
Mitigating controlsNew control for 1810 AP leadAnalysis shows the risk as mitigated for that user only, within the validity dates

Testing GRC changes means proving the control still works, not just that the screen saves.

Most of these are negative as well as positive tests. A workflow test must show that a high-risk request cannot skip the risk owner stage; a firefighter test must show that someone not on the list cannot check out the ID; a mitigation test must show that the control covers only the user and risk it was approved for.

A workflow test is positive and negative at once: the low-risk request takes the short path, and the high-risk one must not reach provisioning without the risk owner.
The Sign-Off Table · thesignofftable.com/academy/sap-sec-301
  1. Change in GRC developmentRule, workflow, connector or rule set change, with a change record.
  2. Transport to GRC qualityConnected to CMQ, with test users and test roles prepared.
  3. Positive and negative testsEach path, approver, provisioning result and log checked against expectations.
  4. Regression sampleStandard request, review and firefighter flows still work end to end.
  5. Approve and transportEvidence attached; change moved to GRC production.
  6. Verify in productionA low-risk smoke test confirms the change is active and connectors work.
The path of a GRC configuration change at Contoso, with the evidence it creates.
The Sign-Off Table · thesignofftable.com/academy/sap-sec-301

Test data for GRC testing

GRC tests need their own test fixtures in CMQ: test users with known role combinations (clean, conflicted, mitigated), test roles that deliberately contain known conflicts for rule set validation, firefighter IDs with test firefighters and controllers, and organizational data that drives reviewer determination. Priya's team keeps a GRC test data sheet listing them, and Sam's team restores them after each CMQ refresh, because a refresh from production would overwrite them.

Background jobs are part of the control

Many Access Control functions depend on scheduled jobs: synchronizing users and roles from connected systems, batch risk analysis, collecting firefighter logs, refreshing dashboards. If a job fails, the screens still work but show stale data, and the control quietly stops. Include job monitoring in the GRC run book, and after any change to connectors or job definitions, check that the next run of each job completed and that its data is current.

When a scheduled job fails, the screens still work on stale data, so each job is part of the control it feeds.
The Sign-Off Table · thesignofftable.com/academy/sap-sec-301
  1. Does the change affect who approves or reviews?Yes → test each path with requesters and reviewers from different org units · No → next
  2. Does it affect what is detected?Yes → validate with known conflicting and clean test roles · No → next
  3. Does it affect what is written to business systems?Yes → verify the result in the target system and client · No → next
  4. Does it change a scheduled job or connector?Yes → check the next run completes and data is current · No → regression sample only
Scoping tests for a GRC change: four questions decide what must be proven.
The Sign-Off Table · thesignofftable.com/academy/sap-sec-301

What would you do?

Nadia's team changes a BRFplus rule so that requests for finance roles are routed to new role owners after a reorganization. In GRC quality, a test request for the AP clerk role reaches the right owner and is provisioned. Priya asks whether the change is ready for production. What is missing?

Key points
  • GRC configuration changes can silently switch controls off; test them like business changes.
  • Test rule sets, workflows, provisioning, emergency access, reviews and mitigation, positive and negative.
  • Keep GRC test fixtures in CMQ and restore them after refreshes.
  • Scheduled jobs are part of the control: monitor them and check their next run after changes.
  • Verify in production with a low-risk smoke test after transport.

Check your understanding · not graded

Lesson check

  1. 1. Which test proves that a new Fiori app was correctly added to the supplier maintenance function?

  2. 2. What is a necessary negative test for a new firefighter ID?

  3. 3. Why must GRC test fixtures be restored after a CMQ refresh from production?

  4. 4. Why are scheduled jobs part of the Access Control controls?