GRC in practice - making requirements part of everyday work

A management system provides a shared structure

Effective management is fundamental to implementation. A quality or information security management system organises objectives, responsibilities, competence, resources and improvement. These elements need to work together so that the organisation can recognise problems and respond effectively.

The shared structure of many management system standards makes it easier to integrate requirements into existing processes. This does not mean that their subject-specific requirements are identical. It does provide opportunities to organise responsibilities, documentation, performance evaluation and improvement together.

This is how I understand GRC: Governance, Risk and Compliance. Governance sets direction, decision-making rules and responsibilities. Risk management helps identify what could disrupt the achievement of objectives and how to respond. Compliance involves establishing which obligations apply and whether they are being met.

These three perspectives should come together around the same problem. We need to understand which legal, customer or internal requirement must be met, who is responsible for action and whether the chosen solution reduces risk. Omitting one of these questions can leave a gap that only becomes apparent during a disruption or a subsequent assessment.

A document is the starting point for verification

During an audit, I ask for evidence of operation. I revisit a related topic in another process and check whether the information forms a consistent picture. If one area describes a particular way of working, it matters whether the people working with it understand their role in the same way.

Consistency does not mean identical answers. Each person may be responsible for a different part of the process. What matters is whether those parts fit together: who initiates an action, who receives information, who decides and what happens next.

The existence of a procedure does not confirm process effectiveness. A document may be current and approved while actual practice still differs from it. Conversations, observation and records of real activities should therefore complement the document review.

I do not equate system maturity with the volume of documentation. Documentation needs to be both sufficient to meet requirements and useful: it should help maintain rules, transfer knowledge and demonstrate that actions were performed. A shared understanding can reduce unnecessary descriptions, but it does not replace required records.

A nonconformity should lead to a lasting process change

The starting point is for every affected area to understand the requirement. Sometimes a nonconformity is what reveals that people previously interpreted it differently or overlooked its impact on everyday work.

Further work requires commitment and an understanding of the cause. A superficial correction may remove the visible error while leaving the conditions for it to recur. Adding a sentence to a procedure or completing a missing record is therefore not always sufficient.

An immediate measure may be necessary to bring the situation under control and limit its consequences. It should not replace addressing the cause. Further actions, responsibilities and a way to check whether the change achieved its intended effect need to be established.

I want the new element to become part of the process: people should understand when to apply it, have the necessary knowledge and resources, and inform the related areas of the change. Closing the nonconformity then rests on a changed way of working.

Meeting requirements without unnecessary workload

A new requirement sometimes adds work: something must be verified, approved, documented or communicated. Not all of that effort is unnecessary. It is still worth checking whether the way the requirement is implemented introduces avoidable repetition and manual handling.

Automation is a familiar way to improve production work. I see similar potential in document workflows. Routing a task to the right person, reminding someone of a deadline or organising approvals are examples of activities worth considering for automation.

The process needs to be understood and organised first. Automation will not determine who should make a decision or what constitutes sufficient evidence. If the rules are unclear, a tool may simply pass the problem between people more quickly.

The solution should also account for exceptions and provide a way to check its operation. I would assess the total effort: performing the task, handling errors and maintaining the tool. Automation makes sense when it helps meet the requirement while retaining the necessary control.

PDCA connects quality and information security

The main things I bring from quality are the PDCA approach and attention to detail when checking results. Planning, doing, checking and acting also help me organise work in information security.

Planning establishes the problem, requirements, risk and expected outcome. Implementation requires attention to responsibilities, knowledge and resources. We then check whether the solution works under real conditions. That assessment should lead to retaining effective practices or making another change.

The cycle does not run itself. It needs people to revisit agreements, review evidence and make decisions. Distributing a new procedure does not demonstrate understanding, and completing a correction does not yet confirm effectiveness.

Details matter especially where processes meet. A well-described action may fail to deliver if information does not reach the right person or accountability ends before the result is checked.

How I recognise good work

I consider a solution successful when it meets requirements, effectively reduces risk and is as straightforward as possible to use in everyday work. It matters to me whether it helps others carry out their tasks.

If a requirement has been met but its implementation adds work, we should assess whether that cost is justified. Some controls require effort. That does not remove the need to seek simpler information flows, eliminate repetition and make better use of available tools.

I want to discuss effectiveness with the people using the solution. Do they know what to do? Can they apply the rules in an unusual situation? Does the problem recur? Does maintaining the change require constant manual reminders? These questions help assess whether the solution has become part of the process.

Summary

Confirmation that a requirement has been met is not enough for me. I also want to know whether the solution works within the process, whether people understand it and whether we can maintain its effectiveness without unnecessary workload. This is how I understand the practical connection between governance, risk and compliance.