My first real job role was as a Network Administrator.
I used Cisco devices.
I was progressing rapidly towards Cisco's CCIE exam, the most demanding certification Cisco offered.
I have forgotten many of the details from the training courses.
But there is one rule that I remember - and used last week...
"Follow the data."
Part of the CCIE exam is an 8-hour lab.
During this, you must design and build a fully working network to a set of requirements.
Oddly, you were forced to go to the toilet during the exam.
Not out of a concern for your health...
But because the examiner took the opportunity to break the work you had already completed.
Part of the lab was to recover from other people breaking your work.
This was an unscheduled part of the lab, which could easily damage a candidate's confidence.
So a critical part of the preparation was to understand...
What's the best way to find and recover from this situation?
Luckily, a great mentor let me in on the secret - albeit in a zen-like riddle.
"Follow the data."
After several weeks of puzzling, I eventually understood what this meant.
Start at one end of the network and at the most fundamental level...
Is there a cable connecting the device?
Then...
Step by step.
Link by link.
Network by network.
Continually repeating the phrase "I'm starting here and trying to get to there... what's my next step?"
...until the problem is found.
We are often so focused on individual teams or systems that we forget how information flows through our businesses.
When I lead discovery workshops for M365 Conditional Access reviews, I use the "follow the data" approach.
Starting with a customer...
What sensitive data do they share with you?
Then... step by step.
Process by process.
What systems are used?
Who should have access to the data?
How is the data secured?
Often, the conversation starts easily.
"The sales team captures the lead and puts it into the CRM..."
But there comes a point when I realise I am asking questions no one has asked before.
Or, at the very least, not since the system was first designed.
Security gaps don't appear in systems that are thought about daily.
They appear in systems that have been forgotten about.
And from questions that haven't been asked.
It's a problem especially prevalent in inherited systems and processes.
So maybe this week is the time to put you and your team under exam pressure.
And ask the question - If our processes or systems broke, would we know how to fix them?