Organisations are often trying to gain assurance over technology environments that change far more quickly than their traditional governance, risk and compliance (GRC) processes.
Access permissions change. Cloud resources are created and reconfigured. New applications are introduced. Suppliers, data flows and cyber risks evolve. Yet oversight may still depend on periodically exporting data, circulating spreadsheets and collecting screenshots.
These activities can provide useful evidence, but usually only about the organisation’s position when the information was collected. By the time a review is completed, user access, system configurations or other relevant conditions may have changed.
GRC Engineering offers a more integrated approach by incorporating controls, monitoring and evidence collection into the systems and processes themselves.
What is GRC Engineering?
GRC Engineering is an emerging discipline that applies engineering principles and technical capabilities to governance, risk and compliance.
Its purpose is to consider how controls can be designed, operated, monitored and evidenced through the systems and processes an organisation uses.
This might involve configuring a system to enforce an agreed rule, using workflows to manage approvals and exceptions, obtaining information directly from a reliable source or identifying when defined control conditions are no longer being met.
More than automating a checklist
Automation is an important part of GRC Engineering, but it is not the starting point.
Automating a poorly designed control may simply allow an ineffective process to operate more quickly. Before considering the technology, an organisation needs to understand the risk the control is intended to address, what it should prevent or detect, what information can be relied upon and who will investigate when it does not operate as intended.
It can then consider whether technology could enforce the control, monitor its operation or produce relevant evidence.
Digitising a checklist can make an existing process quicker or easier. GRC Engineering goes further by reconsidering how the control is designed and whether it can be incorporated into the system or process itself.
A common problem in assurance work is not that evidence does not exist. It is that it has to be reconstructed after the event from spreadsheets, emails and several different systems.
Consider a user access review
A traditional access review may involve exporting a list of users, sending spreadsheets to managers, chasing responses and manually storing the completed evidence. Any access identified for removal may then need to be followed up separately.
The review may be completed, but the data can quickly become outdated. Decisions may not be recorded consistently, higher-risk access may not receive sufficient attention, and unresolved exceptions can be difficult to track.
A GRC Engineering approach would begin with the control objective and consider how the review could operate more effectively:
- Could access information be obtained directly from the identity or source system?
- Could it be compared with authoritative HR information?
- Could managers review and record their decisions through a controlled workflow?
- Could privileged, unusual or incompatible access be prioritised?
- Could rejected access and overdue actions be directed to the people responsible for resolving them?
- Could review decisions and subsequent actions be retained as evidence?
The result would create clearer ownership, more consistent execution and a more reliable record of the decisions made.
Some organisations may already have technology capable of supporting this approach. Microsoft Entra, for example, supports recurring access reviews. Azure Policy can assess resources against defined rules, while AWS Config and AWS Audit Manager can support configuration monitoring and automated evidence collection.
These capabilities do not, by themselves, demonstrate that a control is effective. The rules must be appropriate, the relevant systems and resources must be within scope, the underlying data must be reliable and exceptions must be addressed. System-generated evidence can only show what the technology was configured and able to evaluate.
Bringing GRC into system design
GRC Engineering can be particularly valuable when considered before a new system or service goes live.
Secure by design and privacy by design are familiar concepts. Governance, risk and compliance requirements should be considered alongside them.
During implementation, teams should consider how access will be requested, approved, reviewed and removed; how privileged activity will be controlled; how configurations and exceptions will be managed; and what information will be needed for oversight and assurance.
Considering these questions early can avoid discovering later that the necessary data is unavailable, important decisions have not been retained or controls depend on time-consuming manual workarounds.
What does this mean for internal audit and assurance?
GRC Engineering does not remove the need for internal audit, risk specialists or professional judgement.
Internal audit will still need to examine the design of the control and decide how far the system-generated evidence can be trusted. That includes understanding what the monitoring covers, where its data comes from and what happens when it identifies an exception.
There is also an important distinction between management and assurance responsibilities. Management remains responsible for designing, implementing and operating controls. Internal audit can offer insight and constructive challenge, but it must protect its independence and objectivity if it will later provide assurance over those controls.
Heads of Audit and GRC are unlikely to build these technical solutions themselves. They do need to work closely with the people who will. They do, however, need to work more closely with technology, security and system owners and ask different questions:
Could the control be incorporated into the process? Could the system prevent a control failure rather than identify it afterwards? Could exceptions be identified sooner? Could evidence be obtained directly from its source?
More timely and dependable evidence could allow assurance professionals to spend less time gathering information and more time considering the questions that require judgement: whether the right risks are being addressed, whether controls remain appropriate and whether the organisation responds effectively when something goes wrong.
Better-designed controls, better assurance
GRC Engineering does not mean every control should be automated or that checklists, spreadsheets and manual testing no longer have a place. The right approach will depend on the risk, the organisation and the technology available.
By considering control, monitoring and evidence requirements earlier, organisations can create more reliable controls and a stronger, timelier basis for oversight and assurance.
This requires closer collaboration between GRC, internal audit, security, technology and operational teams. Where that collaboration works well, organisations can gain more timely oversight without relying so heavily on evidence reconstructed after the event.
This article was inspired by AJ Yawn’s ISACA webinar and his pioneering work in developing and advancing the concept of GRC Engineering: AJ Yawn’s work on GRC Engineering
