Why Your Information Security Consultants Aren't Delivering - And How to Fix It

Let me tell you something I've seen happen more times than I care to count. A company hires an information security consultant - sometimes a very good one - and six months later, the executive team is frustrated, the IT department is pointing fingers, and the security posture hasn't actually improved. Everyone did "something," but nobody can tell you exactly what that something was or whether it made any difference.

This isn't a consultant quality problem. More often than not, it's a structure problem.

Over the years working with companies across industries - from startups handling sensitive customer data to established enterprises navigating compliance requirements - I've noticed a consistent pattern. The organizations that get real value from their security consultants are the ones that set up clear expectations, controls, and accountability before the engagement even starts. The ones that struggle? They treat hiring a consultant like hiring a contractor to fix a leaky pipe. Show up, do the thing, leave. That approach doesn't work in cybersecurity.

Here's what actually does.

Define Who Does What - In Writing

This sounds obvious, but I've walked into situations where nobody had actually answered this question. When your information security consultant makes a recommendation, who is responsible for implementing it? Your IT team? The consultant themselves? A third-party vendor?

If you don't define this upfront, you'll discover the gap at the worst possible moment. I've personally experienced situations where an IT administrator refused to implement security controls recommended by our team, saying it "wasn't in their job description." That project stalled for weeks while the client tried to sort out internal politics - all while paying for consulting time.

Put the responsibilities in writing. Be specific. If your IT team is standing up a new server, at what point do they loop in your security consultant? Before the purchase order? During configuration? After go-live? These aren't trivial questions. A server that goes into production without security review can introduce vulnerabilities that take months to discover and remediate.

Never Let Security Report to IT

This is a hard rule for me, and I won't bend on it. When information security reports to the IT department, security always loses. Not because IT professionals are bad people - most of them are excellent at what they do - but because their incentives are misaligned.

IT is measured on uptime, performance, and getting things done quickly. Security often means slowing things down, adding friction, and saying no to things that seem perfectly reasonable from a pure functionality standpoint. When the person responsible for security has to ask permission from the person responsible for getting systems up and running, you've already created a conflict of interest.

Security requirements need to come from the C-suite. When a CEO or COO is the one saying "this is non-negotiable," the conversation changes entirely. IT complies, not because they were overruled, but because the business priority is clear. Your information security consultant's recommendations carry far more weight when they're backed by executive mandate rather than another department's request.

Build In Verification - Don't Take Anyone's Word For It

Here's something that will make some IT teams uncomfortable, but it needs to be said: false reporting happens. Not always maliciously - sometimes it's wishful thinking, sometimes it's someone marking a task complete when they technically did something but not quite the thing you needed. In my experience, it happens more often than most executives realize.

This is why verification can't rely solely on self-reporting. Your security consultant should have access to verify that recommended controls are actually in place, not just confirmed via email. Ideally, this verification happens through a third-party tool whose output neither the IT team nor the consultant can modify. The report should be immutable - a snapshot of reality, not a curated version of it.

If you're investing real money in a security program, you deserve to know whether the controls you paid for are actually running.

Create KPIs for Everyone Involved

If security doesn't appear in someone's performance metrics, it won't appear in their priorities. This is true for your employees, and it's equally true for your consultants.

For your internal team, security KPIs might include things like the percentage of endpoints with endpoint detection enabled, patch compliance rates, or the number of open critical vulnerabilities older than 30 days. These aren't punitive - they're clarifying. They tell people exactly what "good" looks like from a security standpoint and give them something concrete to work toward.

For your consulting team, KPIs should be baked into the contract. What are they expected to deliver, and by when? How will you measure whether the engagement was successful? A consultant who can't answer these questions before the project starts is a consultant who may not be able to answer them afterward either.

At Atlant Security, we help clients define KPI requirements for our own work and for their internal IT teams. It keeps everyone honest - including us.

Give Everyone Visibility Into Progress

One of the most common failure modes in security consulting engagements is the black box problem. The consultant does work. The IT team does work. The executive team gets a report four weeks later. Nobody knows in real time whether things are on track, behind schedule, or stuck because of a dependency nobody flagged.

We solve this by setting up project dashboards for every client engagement. Not elaborate, high-maintenance things - just a shared view where the relevant stakeholders can see what's been completed, what's in progress, and what's blocked. This single practice eliminates more friction than almost anything else. Executives don't have to chase updates. IT doesn't have to write status reports nobody reads. The consultant doesn't have to field the same "where are we?" question every week.

Transparency isn't just nice to have in a security engagement. It's a control. It keeps the project moving and keeps everyone accountable to the timeline.

Understand the Full Scope of What You're Buying Into

Let's talk about what an average security project actually costs - not just in dollars, but in time and organizational attention.

Take an information security assessment as an example. On paper, it might be a two-week engagement. In practice, it's considerably more. There are pre-sales meetings that pull in executives, IT staff, and finance. There are knowledge-transfer sessions, access provisioning, document collection, and interviews. During the assessment, your team has to be available - sometimes significantly so. And after the assessment, there are readout meetings, remediation planning sessions, and follow-up questions.

If you go into this expecting two weeks of work and walk out surprised by the total time investment, you're going to feel burned - even if the consultant delivered exactly what was promised.

The risks run both ways, too. As the client, you risk wasting time and money if the project is poorly scoped or your team isn't available to support it. You also risk getting an excellent deliverable and then doing nothing with it - which, unfortunately, is remarkably common. Companies prioritize urgent operational issues, slide the security report to the bottom of the stack, and revisit it six months later when something goes wrong.

On the consulting side, we carry the risk of walking into engagements where internal politics we weren't told about create resistance at every step. Or where the information we're given during the assessment isn't accurate, which compromises the quality of everything we produce.

Experienced consultants ask about these risks upfront. As a client, you should be prepared to answer honestly - and to ask the same questions of your own organization before the engagement begins.

The Bottom Line

Hiring an information security consultant is not a passive activity. The companies that see real, lasting improvement from these engagements are the ones that show up as active participants - defining responsibilities, enforcing accountability, demanding visibility, and treating security as a business priority rather than a compliance checkbox.

The controls I've described above aren't bureaucratic overhead. They're the difference between an engagement that produces a report and an engagement that actually makes your organization more secure. I've seen both. I know which one you want.

If you're thinking about bringing in external security expertise and want to understand what a properly structured engagement looks like, I'm happy to walk you through our approach. We've built these controls into every project we run - because we've learned, sometimes the hard way, that structure is what makes expertise actually work.

---

Alexander Sverdlov is the founder of Atlant Security, a cybersecurity consulting firm specializing in virtual CISO services, IT security audits, and compliance readiness. He is the author of two information security books and has spoken at major cybersecurity conferences across Asia and at a United Nations cybersecurity event.