The Auditor Is Coming: The First 180 Days in GRC

GRC stands for governance, risk and compliance. The three words describe three jobs that are easy to blur together.

• Governance is who decides what, and how those decisions are written down. Who can accept a risk? Who approves a policy? Who is told when something goes wrong?
• Risk is working out what could hurt the organisation, how badly, and what to do about it. It ends in a decision, not a score.
• Compliance is showing that you meet the rules you have agreed to or are bound by: laws, contracts, standards and your own policies.

If you only remember one sentence, make it this one: GRC exists so that leaders make risk decisions on purpose, and can explain them later. An audit report, a certificate or a clean questionnaire is a sign that this works. It is not the work itself.

Who you work for

You work for the organisation, through whoever owns security risk. That might be a CISO, a CIO, a chief risk officer or a founder. You do not work for the auditor. The auditor checks your work; they are not your customer. Treat them with respect and honesty, but do not let their checklist become your whole job.

You also work with nearly everyone. Engineers own controls. HR owns joiners and leavers. Procurement owns supplier contracts. Legal owns contracts and regulators. Your job is to make the system hang together, not to do every part of it yourself.

What a normal week looks like

• Chasing evidence that a control ran: a review, a backup test, an access recertification.
• Updating the risk register after a change, an incident or a new supplier.
• Answering a customer security questionnaire, using answers that are true today.
• Helping a team write or update a procedure so it matches what they actually do.
• Preparing a short report for leadership on open risks and overdue actions.

Rule of thumb:Rule of thumb: if a task produces paper but changes no decision and no behaviour, ask why you are doing it. Sometimes the answer is a real obligation. Often it is habit.

In your first week, write one paragraph in your own words: what is this organisation trying to protect, and from what? You will rewrite it many times. That paragraph is the start of your job.

You will hear many names in your first week. Some are certifications the company holds. Some are laws that apply whether anyone planned for them or not. Some are slides from a project that stopped two years ago. Your first job is to sort them.

Three kinds of obligation

Facts worth knowing

• ISO/IEC 27001:2022 Annex A lists 93 controls, down from 114 in the 2013 edition, grouped into four themes: organisational, people, physical and technological.
• You do not have to use every Annex A control. You decide your controls through risk treatment, then compare them with Annex A so you do not miss one. The Statement of Applicability records the result.
• NIST CSF 2.0, published 26 February 2024, has six functions: Govern, Identify, Protect, Detect, Respond and Recover.
• NIS2 member states had until 17 October 2024 to put the directive into national law. It makes top management accountable for cybersecurity risk-management measures.
• DORA is Regulation (EU) 2022/2554. It has applied since 17 January 2025 to many types of financial entities and covers ICT risk, incidents, testing and third-party providers.
• PCI DSS v4.0.1 was published on 11 June 2024. It added and removed no requirements. v4.0 was retired on 31 December 2024.

Build your obligations list

1. Ask the CISO, legal and sales: what certificates do we hold, what laws apply, and what do our biggest contracts promise?
2. For each item, write who checks it, how often, and when the next check is due.
3. Note who owns it today. "Nobody" is a valid and important answer.
4. Mark anything that is only mentioned in old slides. Ask whether it is still in scope.

Rule of thumb:Many controls satisfy several frameworks at once. Map controls once and point each framework at them, rather than running a separate programme per framework.

Somewhere there is a risk register. It might be a spreadsheet, a tool, or a tab in a board pack. There may be more than one. Your job in week one is to find out which one people actually use to make decisions.

Test the register in an hour

1. Pick five risks at random.
2. For each one, ask the named owner: do you know you own this? When did you last look at it?
3. Check the controls listed against it. Do they exist? Is there recent evidence?
4. Check the dates. When was each risk last reviewed?
5. Look for big risks that are missing: a key supplier, an old system everyone is afraid to touch, a new AI tool.

This small test tells you more than reading the whole register. You will usually find three kinds of row: live risks with real owners, risks owned by someone who left, and risks owned by a team name rather than a person.

Ownership is the first fix

A risk owner is the person with the authority and budget to decide what happens to the risk. It is not the person who writes the entry, and it is usually not you. If an owner does not know they own a risk, the risk is not being managed. It is being stored.

• Give every risk one named person, not a team or a role that nobody holds.
• Agree the owner with their manager, not only with them.
• Record the decision: treat, accept, transfer or avoid, with a date to look again.
• Separate the risk owner from the control owner. They are often different people.

Rule of thumb:Write risks as cause, event and impact: "Because backups are not tested, a ransomware attack could cause a week-long outage of billing." That sentence tells an owner what to fix.

By the end of your second week you should be able to name the top ten risks, their owners and when each was last reviewed. If you can, you already know more than many people in the building.

Evidence is anything that shows a control did what it claims. An auditor wants to see that the control is designed sensibly and that it actually ran during the period they are checking.

What good evidence shows

• What ran: the control, by name or ID.
• When: a date and time that falls inside the audit period.
• On what: the systems, people or records in scope.
• Who did it or approved it.
• The result, including any exceptions and what happened to them.

A screenshot can be good evidence if it shows all of that. A cropped screenshot with no date, no system name and no context is weak, because it could come from anywhere. An exported report, a ticket with an approval, or a log with timestamps is usually stronger.

Stop the scramble

1. For each control, write down what evidence it produces and where that evidence lives.
2. Agree a schedule with each control owner: monthly, quarterly or per event.
3. Store evidence in one place, named consistently: control, period, date.
4. Check a sample yourself each month. Ask: would a stranger understand this?
5. Record gaps as soon as you find them, rather than hoping to fill them later.

Rule of thumb:Never create evidence after the fact and date it to look older. Backfilled or altered evidence turns a small gap into an integrity problem, and auditors are trained to spot it.

Sampling, in plain words

Auditors rarely check every record. They pick a sample, such as some leavers from the year, and ask for proof each one was handled. You should do the same check yourself first. If your own sample fails, you have time to understand why.

Evidence also expires in practice. A penetration test from two years ago or an access review from last spring may not speak to the current period. Track when each piece of evidence goes stale, just as you track when a policy is due for review.

Most security policies fail for the same reason: they try to do everything. They mix intent, rules and step-by-step instructions, so they are long, out of date within months, and read only during audits.

Three documents, three jobs

How to write one

1. Start from the decision. What must people do or not do? Write it as a short rule.
2. Say who it applies to and who owns it.
3. Say what happens when someone needs an exception, and who can approve it.
4. Remove anything a team will change next month. Move it to a procedure.
5. Read it aloud to someone it applies to. Fix every sentence they ask about.
6. Set a review date and put it in a calendar, not only in the document.

Use short sentences and plain words. "Staff must lock their screen when they leave their desk" beats "Personnel shall ensure that endpoint devices are secured against unauthorised access when unattended." Both say the same thing. Only one gets read.

Rule of thumb:If a policy says something nobody does, you have two honest options: change the practice or change the policy. Leaving the gap is how controls end up existing only on paper.

Policy sprawl

Every incident tempts someone to write a new policy. Resist it. Ask first whether an existing policy already covers it and simply needs a clearer rule. Fewer, shorter documents that are actually followed are worth more than a large library nobody opens.

Keep a register of every controlled document: name, owner, version, approval date and review date. Auditors will ask for it, and it is the simplest way to find documents that have quietly gone stale.

Risk appetite is the amount and type of risk an organisation is willing to take to reach its goals. It is set by leadership, often the board. It is not set by GRC. Your job is to help leaders say it clearly, then use it consistently.

Many appetite statements say something like "we have a low appetite for cyber risk." That sounds sensible and helps nobody. A risk owner cannot use it to decide whether to delay a launch or accept an unpatched server.

Make it usable

• Split it by area: customer data, availability of key services, regulatory standing, new technology.
• Give each area a boundary people can test, such as how long a key service may be down, or which data may never leave approved systems.
• Say who can accept risk at each level, and what must go higher.
• Say how long an accepted risk lasts before it must be reviewed again.

Appetite, tolerance and residual risk

Appetite is the overall stance. Tolerance is the specific line you will not cross in one area. Residual risk is what remains after your controls. When residual risk sits above the line, someone with the right authority must decide: add controls, accept it for a set time, transfer it, or stop the activity.

Rule of thumb:An accepted risk with no expiry date becomes permanent by accident. Every acceptance needs a review date and a named person.

Testing it

Take three real decisions from the last quarter, such as a delayed patch, a new supplier or a rushed launch. Would the appetite statement have told the owner what to do? If not, the statement needs work. Bring those examples to leadership; real cases change wording faster than theory.

Revisit appetite at least yearly and after a major change, such as an acquisition, a new market or a serious incident.

Sooner or later you will find something wrong, or someone will find something you missed. This is not a sign you are bad at the job. It is the job. A GRC function that never finds problems is usually not looking.

Three common situations

• A failed control. The quarterly access review did not happen for two quarters. The control exists; it just did not run.
• A finding you missed. An auditor spots a supplier with access to customer data that was never assessed.
• A control that only exists on paper. The policy says logs are reviewed weekly. Nobody has ever done it, and there is no tool that would make it possible.

The third one is the most serious, because everyone believed it was working. It is also the most common. Paper controls usually come from copying a template or writing what an auditor wanted to hear.

How to report it

1. Confirm the facts quickly. What is wrong, since when, and what is in scope?
2. Tell the control owner and your manager the same day. Do not wait for a perfect picture.
3. Write it down: what happened, the impact you know of, what you do not know yet.
4. Log it as a nonconformity or issue in your tracker, with an owner and a due date.
5. Find the root cause before choosing a fix. "Person forgot" is rarely the real cause.
6. Agree a corrective action and a way to check it worked.

Rule of thumb:Use blameless wording. Describe what the system allowed, not who failed. "The review had no reminder and no backup owner" leads to a fix. "Sam forgot" leads to Sam hiding the next one.

When it was your mistake

Say so plainly: "I missed this supplier when I built the list. Here is how I found it and how I will stop it happening again." People trust a GRC person who owns mistakes far more than one who never seems to make any.

Then fix the process, not just the instance. If one supplier was missed, check how suppliers get onto the list. If one control was on paper, sample a few more. One problem is often a symptom.

Early on, it is tempting to measure what is easy to count: findings closed, policies approved, questionnaires answered. These numbers go up when you work hard. They do not tell anyone whether the organisation is safer.

Activity vs outcome

Closing ten small findings can matter less than fixing one finding on a critical system. Weight your reporting by risk, not by count.

A short, honest dashboard

• The top risks, their owners, and whether each moved up, down or stayed the same, with one line on why.
• Overdue actions on high risks, by owner.
• Risks accepted this period, by whom, and when they expire.
• Controls that failed or were found on paper, and what was done.
• One or two trends that matter, such as how long critical findings stay open.

Rule of thumb:Never round a number to look better or drop a metric because it went the wrong way. Once leaders suspect the dashboard is managed, they stop trusting all of it.

Measuring yourself

Some useful questions for your own review at three months: Do leaders ask you before making risk decisions, or only after? Do control owners send evidence without chasing? Are fewer surprises turning up in audits? Can you name the top risks and their status without looking? None of these is a percentage, and all of them matter.

Keep metrics few and stable. Changing the dashboard every quarter makes trends impossible to read.

Before you add a metric, write down the decision it should change. If a number going up or down would not make anyone do something different, it belongs in your working notes, not on the leadership dashboard. Ask the person who will read it what they would do with it, and listen to the answer.

ISO management system standards, including ISO/IEC 27001 and ISO/IEC 42001, require top management to review the system at planned intervals. Auditors will ask for the minutes. More importantly, it is the one meeting where leaders formally look at your whole programme.

What usually goes in

• Status of actions from the last review.
• Changes inside and outside the organisation that affect security, such as new laws, products or suppliers.
• Changes in the needs and expectations of interested parties, such as customers or regulators.
• Performance: nonconformities and corrective actions, monitoring results, audit results, and whether objectives were met.
• Feedback from interested parties, the risk assessment results and the status of risk treatment.
• Opportunities to improve.

Check the exact required inputs in the edition of the standard you are certified to. The 2022 edition of ISO/IEC 27001 added changes in the needs and expectations of interested parties to the management review inputs.

Running it well

1. Send a short pack a few days ahead. Lead with the decisions you need.
2. For each decision, give the options, your recommendation and the risk of doing nothing.
3. Keep the meeting to the decisions. Reading slides aloud wastes the room.
4. Record each decision with an owner and a date.
5. Start the next review by checking those actions.

Rule of thumb:Minutes must show decisions and actions, not only that the meeting happened. "Reviewed and noted" for every item tells an auditor the review was a formality.

After the meeting

Send the minutes within a few days, while people still remember what they agreed. Put each action into the same tracker you use for nonconformities and risks, so it is chased like any other piece of work. If an action has no owner when the minutes go out, it will not be done.

Keep the pack and the minutes together in your documented information register. At the next audit, the auditor will usually ask for the last review and then follow one or two actions through to see whether they were done.

If leaders will not attend, say so plainly to your manager. A management review without top management does not meet the requirement, and it suggests governance problems an auditor will notice.

A certification audit for ISO/IEC 27001 or ISO/IEC 42001 happens in steps. Knowing what each step checks stops you over-preparing for one and under-preparing for the other.

Before stage 1

1. Confirm the scope in writing: which locations, teams, systems and services are in.
2. Make sure your Statement of Applicability matches your risk treatment decisions.
3. Run at least one internal audit across the scope, and act on what it finds.
4. Hold a management review with real decisions recorded.
5. Read your own documents as if you were the auditor. Fix contradictions.

Between stage 1 and stage 2

Stage 1 often ends with areas of concern. Treat each one as a deadline. Stage 2 will look at whether you addressed them. This is also the time to walk each control owner through what they may be asked.

Rule of thumb:A certificate covers the scope written on it. Check the scope statement carefully before it is issued, and never describe the whole company as certified if only part of it is.

During the audit

Keep a simple log of every evidence request: what was asked, who is fetching it, and when it was sent. Answer what was asked, not more. If something cannot be found, say so and say when you will know. Meet the auditor briefly at the end of each day to hear what they found, so nothing in the closing meeting is a surprise.

After certification, the work continues. Surveillance audits come each year, and the certificate runs on a three-year cycle with recertification before it ends. Plan your internal audits and management reviews around that calendar.

Auditors interview people. They want to hear from the people who run controls, not only from you. This makes many GRC people nervous. It should not, if the system is real.

Preparing people for interviews

• Tell them what the audit is for and roughly what they may be asked.
• Ask them to describe what they actually do, in their own words.
• It is fine to say "I do not know, but I can find out" or "that is handled by another team."
• Bring evidence they would normally use, such as a ticket or a report.
• Never script answers. Scripted answers fall apart at the second question.

Kinds of finding

Certification bodies grade findings. The usual grades are a major nonconformity, a minor nonconformity and an observation or opportunity for improvement. A major usually means a requirement is not met at all, or a failure that puts the system in doubt. A minor is a single lapse that does not break the system. Check your certification body's own definitions; they set the rules for your audit.

Writing a corrective action

1. Fix the immediate problem, such as removing the leaver's access.
2. Find the root cause. Ask "why" until you reach something you can change.
3. Check whether the same cause affects other areas.
4. Choose an action that removes the cause, with an owner and a date.
5. Say how you will check it worked, and when.
6. Keep the evidence of each step.

Rule of thumb:"Retrain staff" is the most common weak corrective action. It is only right when the cause truly was missing knowledge. If the cause was a missing step in a process, change the process.

Corrective and preventive action, often shortened to CAPA, is the habit behind all of this. Auditors at surveillance visits will check that last year's actions were done and that they worked. A finding that comes back is a sign the root cause was not found.

By month six you will have tried a bit of everything. Some parts will have felt like chores. Others will have kept you up reading at night. That second group is a clue to your path.

1. ISO 27001 or ISO 42001 lead

You run a certified management system: scope, risk assessment, internal audit, management review, and the yearly audit cycle. ISO/IEC 42001 sets requirements for an AI management system and is certified on the same pattern of stage 1, stage 2 and yearly surveillance. If you like structure and seeing the whole system, this suits you. See the ISO 42001 guide.

2. Third-party risk

You assess suppliers before they get access, keep track of them while they have it, and respond when one of them has an incident. It mixes contracts, security questions and relationship work. Practise with the vendor risk scorecard and the third-party breach intake.

3. Privacy

You work on personal data: what is collected, why, where it goes and how long it stays. It sits close to legal. If you like rules applied to real people, this path is rich.

4. AI governance

You help the organisation adopt AI tools with clear owners, risk assessments and limits. It draws on risk management, privacy and supplier risk at once. It is new, so you will often be writing the first version of things.

5. PCI DSS

You protect card data in a specific, detailed standard. PCI DSS v4.0.1 is the current version; v4.0 was retired at the end of 2024. Scope reduction is a big part of the craft. Start with the PCI DSS guide.

Rule of thumb:Laws shape every path. In the EU, NIS2 puts cybersecurity risk management on top management's agenda, and DORA applies to many financial entities. Read the NIS2 guide if you work with EU organisations.

Whichever path you choose, the core stays the same: clear ownership, honest evidence and decisions on purpose.

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.