What GRC Is Not Good At

You have made it to day 180. Before you plan the next year, it is worth being honest about the limits of the work. Knowing them makes you better at it.

Compliant is not the same as secure

Compliant means you met a set of requirements when someone checked. Secure means attackers find it hard to do harm. They overlap, but they are not the same. A certified organisation can still be breached. A small team with no certificate can be well defended.

Be careful with words. If a leader asks "are we secure?", do not answer "we are compliant." Say what you know: which risks are in appetite, which are not, and what you have not checked.

Checkbox culture

• Controls designed to pass an audit rather than reduce a risk.
• Evidence produced for the auditor, not used by the team.
• Risk scores nobody disagrees with because nobody reads them.
• Questionnaire answers that are technically true and practically misleading.

The cure is to keep asking what each control is for. If a team cannot explain the risk a control reduces, either the explanation or the control needs work.

Policy sprawl

Documents pile up. Each one made sense when it was written. Together they become a maze nobody can follow. Once a year, look for documents you can merge or retire. Removing a document is as useful as writing one.

Things GRC cannot do alone

• Patch a system, configure a firewall or detect an intruder.
• Make a leader care about a risk they have decided to ignore.
• Turn a weak engineering culture into a strong one by writing policies.

What GRC can do is make risk visible, make decisions explicit, and make sure the right people own them. That is a lot.

Rule of thumb:Keep one list called "what we have not checked." Share it with your leaders. It is the most honest document in any GRC programme.