What Are We Pretending Is Fine? A Practical Security Culture Audit
This week, the podcast team covered a topic that doesn’t get enough practical attention: the gap between how secure a business thinks it is and how secure it actually is.
The four questions Mauven proposed on Monday are a good diagnostic tool. What I want to do here is turn them into a practical process you can actually complete.
This is a half-day exercise. You don’t need a specialist, a new tool, or a consultant. You need one person with authority to ask questions and record honest answers, a spreadsheet, and a standing commitment to do something with what you find.
I’ll take each question in turn.
Before You Start: Set the Right Conditions
One thing worth establishing before you begin: the purpose of this exercise is accuracy, not blame.
If you have a junior staff member who has been flagging a concern for months and nobody has acted on it, the finding is not that the staff member failed to escalate loudly enough. The finding is that the organisation did not have a functioning escalation process.
If you discover that half your team is using a SaaS tool you didn’t know existed, the finding is not that your team ignored policy. The finding is either that the policy was unclear, or that there was a genuine gap in your approved tooling that nobody addressed.
State this clearly to anyone you involve in the process. You will get more honest answers.
Question 1: What Have We Delayed Because It’s Inconvenient?
What you’re looking for: Security fixes that are on a list somewhere but have not been scheduled, or have been deferred multiple times. These are not fixes that were assessed and deemed low-risk. These are fixes that got bumped because they would require downtime, budget approval, a difficult conversation with a vendor, or time that nobody had.
How to find them:
Step 1. Ask your IT team or MSP for the current patching backlog. Specifically, ask for any items that have been deferred more than once, and for any known vulnerabilities that do not yet have a scheduled remediation date.
Step 2. Ask the same people: “What have we been meaning to fix that keeps getting pushed back?” Write down everything they say. Do not filter or comment while they are talking.
Step 3. Pull the last penetration test or vulnerability assessment report. Look at every finding that was not marked as fully remediated. For each one, check whether it has a scheduled fix date. If it doesn’t, add it to your list.
What to do with the list:
For each item, record: what it is, how long it has been deferred, what the blocker is, and who needs to make a decision to move it forward. Assign each item to a named person.
The items that have been deferred longest are usually the most important ones. That sounds counterintuitive, but extended deferral almost always means the fix is either technically complex, politically awkward, or genuinely expensive. Those are the items most likely to become a problem.
Set a target to address at least one item from this list within the next thirty days. Not all of them. One.
Question 2: Who Has More Access Than They Need?
What you’re looking for: Accounts with admin rights or elevated permissions that are no longer justified by the account holder’s current role. Shared accounts. Former employee accounts that were not promptly disabled. Service accounts with broader access than required.
How to do the review:
Step 1. Generate a list of all user accounts in your Active Directory, Microsoft 365 tenant, or equivalent. Most SMBs can do this in under ten minutes. If you use an MSP, ask them to provide this.
Step 2. Mark every account with admin or elevated permissions. For each one, answer: does this person currently require this level of access to do their job?
If the answer is “probably, but we’ve never checked,” that counts as a no.
Step 3. Look specifically for:
- Accounts belonging to former employees (should be disabled immediately if found)
- Shared accounts (e.g., a generic “admin” login used by multiple people)
- Service accounts used by applications with more access than those applications actually need
Step 4. For each account where you cannot confirm that the current permission level is genuinely required, flag it for review. Do not immediately remove access: confirm the current role requirements with the account holder’s line manager first.
The principle to apply:
Every account should have the minimum access required to perform its function. This is called the principle of least privilege. Applying it reduces the blast radius of any breach: if an account is compromised, the attacker’s access is limited to what that account was permitted to do.
This review should take one to two hours in an organisation of under fifty people. It should be repeated every six months as a minimum.
Question 3: What Tools or AI Applications Is the Team Actually Using?
What you’re looking for: Applications, browser extensions, AI tools, and cloud services that staff are using to do their work, which have not been formally assessed and approved.
How to find them:
Step 1. Ask. Directly, at a team meeting or via a short form, ask: “What applications or tools do you use regularly that you would describe as ‘not the official ones’?” Frame it explicitly as a governance exercise, not a disciplinary one.
Step 2. Ask your IT team or MSP to pull a list of cloud applications that have been granted access to your Microsoft 365 or Google Workspace environment. Most SMBs are surprised by how many there are.
Step 3. Check your payment systems. Look for recurring small subscriptions to SaaS tools that may have been set up by individual staff members on company cards or expense accounts.
Step 4. Ask specifically about AI tools. Which staff are using AI assistants? What type of content are they putting into those tools? Are any of them pasting customer data, financial information, or confidential correspondence into a consumer AI application?
What to do with what you find:
For each tool identified, record: what it does, who uses it, what data it accesses, and whether it was formally assessed before adoption.
Assign each tool to one of three categories:
- Approved with governance: The tool is assessed as acceptable, the business formally adopts it, and clear guidance is issued on appropriate use.
- Replace: There is a better-governed alternative that meets the same need. Communicate a transition timeline.
- Discontinue: The tool presents unacceptable risk or has no legitimate business justification.
Do not simply ban all unapproved tools without identifying why staff are using them. If five people are using a SaaS project management tool that isn’t the official one, the question to ask is what gap the official tool has that this one fills. Address the gap, then migrate to the approved solution.
Question 4: Where Do People Currently Raise Concerns, and What Happens When They Do?
This is the hardest question, because it requires honest reflection on organisational culture rather than a technical audit.
What you’re looking for: Whether the people closest to your systems have a clear, functional route to raise security concerns, and whether doing so has historically produced action.
How to assess this:
Step 1. Ask your IT staff or MSP directly: “If you identified a security concern that wasn’t urgent enough for an immediate escalation, how would you raise it, and what would you expect to happen?”
If the answer is “I’d mention it to [person] and hope it got followed up,” that is not a process.
Step 2. Think back over the last twelve months. Have any security concerns been raised informally, in passing, or in a way that did not result in formal follow-up? If so, why?
Step 3. Ask a non-technical staff member: “If you noticed something unusual with your access to a system, or a colleague behaving oddly around company data, what would you do?” Their answer will tell you a lot about whether your security culture has reached beyond the IT team.
What to put in place:
A functional concern-raising mechanism for security does not need to be complicated. Options include:
- A standing item on the weekly operations meeting agenda: “What security issues are we aware of this week?”
- A shared document or simple ticket category where concerns can be logged
- A direct line to whoever is responsible for security decisions, with a clear commitment to respond within a defined timeframe
The critical element is that concerns raised through this route must visibly result in action, or at least in a clear explanation of why the concern does not require action. The mechanism breaks down the moment someone raises something and gets no response.
Building the Output: Your Security Culture Register
At the end of this exercise, you should have a simple document with four sections:
Section 1: Deferred fixes. List of known security issues with deferred remediation dates, assigned owners, and target resolution dates.
Section 2: Permission anomalies. List of accounts flagged for review, with current status and action required.
Section 3: Shadow tools. List of unapproved tools in use, with categorisation (approved, replace, discontinue) and timeline.
Section 4: Concern-raising gaps. Description of the current process, identified gaps, and proposed improvements.
This document does not need to be shared widely. It needs to be owned by someone with authority to act on it, reviewed quarterly, and updated as items are resolved.
How to Turn This Into a Competitive Advantage
This exercise produces a document that most of your competitors do not have.
Suppliers, clients, and insurers are increasingly asking for evidence of active security management, not just compliance certification. Being able to describe your security posture in specific terms, including what known issues exist and how they are being managed, demonstrates a level of security maturity that a Cyber Essentials certificate alone does not.
Cyber Essentials v3.3, going live in April 2026, will require stronger evidence of active control, particularly around cloud services, MFA, and device management. Organisations that have been running this kind of internal audit regularly will have a much shorter path to certification.
How to Sell This to Your Board
Three talking points:
1. This exercise reduces your ICO exposure. The ICO’s enforcement guidance treats an organisation that has identified a risk and not addressed it far more harshly than one that addressed a risk promptly upon identification. Having a register of known issues with active management demonstrates due diligence.
2. This is insurance hygiene. Cyber insurers are increasingly asking for evidence of active security management at renewal. An organisation that can produce this document is in a stronger position than one that cannot.
3. The cost of the exercise is minimal. Half a day of one person’s time. The cost of not having this information is documented: £195,000 average for a significant incident, plus regulatory risk.
What This Means for Your Business
Here is the complete checklist:
Week one:
- Schedule a half-day for this exercise
- Ask IT/MSP for the patch backlog and any deferred remediation items
- Generate a full user account list with permission levels
- Ask the team what tools they actually use
Week two:
- Complete the permissions review
- Categorise shadow tools (approve, replace, discontinue)
- Assess the current concern-raising process
- Create the Security Culture Register
Week three:
- Assign owners to all items in the register
- Schedule the first remediation item
- Put the concern-raising mechanism in place
- Communicate to the team what you found and what you’re doing about it
That last step matters more than it might seem. When staff see that the exercise produced action, they are more likely to raise concerns in the future. Which is exactly the security outcome you are trying to achieve.
Sources
Related Posts:
- Confidence Is Not a Security Control — Monday’s Podcast
- The Overconfidence Tax — Tuesday
- Cyber Attack Recovery Plan: You’ve Got a Flood Plan But No Cyber Plan