🎃 The GRC Processes That Died Years Ago Still Haunt Your Program

Every GRC program has a process nobody can explain and everybody still follows.

A spreadsheet goes to managers on the first Monday of the month. Someone signs an access review for a system the company migrated off. Ask why and you hear "the auditor asked for it."

These are zombie processes: practices whose reason died while the work carried on. Each one costs someone outside GRC their time, and teaches them that GRC makes people do things for no reason.

Where the name comes from

In Unix, a finished process keeps its slot in the process table until its parent calls wait() to collect it. Until then it's a zombie. If the parent dies, PID 1 adopts it and reaps it.

In GRC, the parent is whoever created the process and knew why. When they leave, the GRC team adopts it, and the GRC team is a PID 1 that never reaps. Strictly, that's an orphan: a Unix zombie does nothing, while yours is still using up people's weeks.

Most of them were sensible once. In When a Screenshot Is Least Privilege, I argued that the rituals we mock had a point, and gave two questions to answer before removing anything: what did this solve, and what has changed since? Often the parent is your first GRC lead, whose instincts are still running your program. Those were good calls for a 2021 company, and it's now three times the size.

Why nobody kills them

A process gets mapped to a control and then passes an audit. If your policy says the spreadsheet goes out monthly and gets signed, the auditor checks that it went out and got signed. Few ask whether the signature changed a decision. New hires never met the parent, so they learn it at onboarding and defend it.

One incident and one email create a process. Retiring it takes proof that nothing breaks and a policy change.

That's your GRC program's missing garbage collector. Add six processes a quarter, retire two, and you have thirty-two more by the end of year two.

The life of a GRC zombie.

Five signs you've found one

• Nobody can name who reads the output. Ask whoever produces it where it goes, then ask that person what they do with it.

• The owner has left. Join owners to HR. Distrust anything reassigned to GRC.

• "The auditor asked," with no year. Find the finding. Until you do, the reason is unverified.

• People route around it. Look for shortcuts and "paste this into the form" docs.

• A monthly task only gets done before the audit. The audit is the only consumer left.

Start with your risk register

Your risk register was accurate once, and it never records when a row stopped being true. Its dead rows are the easiest to query: owner gone, treatment long overdue, system decommissioned.

-- Postgres
SELECT r.*, e.email IS NULL AS owner_left
FROM risks r
LEFT JOIN employees e ON lower(e.email) = lower(r.owner) AND e.active = true
LEFT JOIN systems s ON s.id = r.system_id AND s.decommissioned IS NOT TRUE
WHERE r.status IS DISTINCT FROM 'closed'
  AND (e.email IS NULL
       OR (r.status = 'in_progress'
           AND COALESCE(r.treatment_due, '-infinity') < CURRENT_DATE - 180)
       OR (r.system_id IS NOT NULL AND s.id IS NULL));

In a spreadsheet, three filter columns. If only the owner left, reassign outside GRC.

When you close a risk the board has seen, bring a replacement describing today's exposure, or a note that it's gone.

The hunt

Ask three teams outside GRC: "What do we make you do that you don't understand?" For each one, check whether the output changes a decision anyone makes, and answer the two questions in writing. Then give it a verdict.

• Keep if the reason holds and the output gets used. Name an owner and a review date.

• Revive if the reason holds but the practice no longer fits. Redesign it around what changed.

• Reap if the reason is gone. Remove it and write down what does its job now.

Before removal, check contracts and regulation, and tell your auditor.

If mapped, run old and new together until the period ends. Then remove it and update the policy and mappings, plus the SoA if an Annex A control changes.

Stop making new ones

Give every new process a manifest with a date.

process: vendor-security-review-for-ai-tools
owner: [email protected]
reason: AI tools arrive faster than procurement sees them
consumer: security engineering
decision_it_changes: whether the tool gets SSO, and with which scopes
review_by: 2027-04-29

If you can't fill in consumer and decision_it_changes, don't create the process. An auditor can be the consumer if you name the requirement. A scheduled job on review_by returns overdue ones to the hunt.

Pick one process this month and give it a verdict in writing. Reply with the oldest one you find, and the year it was born.