Somewhere this week, someone is starting a new role and discovering that the digital estate they've just become responsible for is held together with duct tape, optimism, and the institutional memory of a developer who left eighteen months ago.
If that's you - congratulations on the job, and I'm sorry about the job.
I've been on the other side of this conversation more times than I can count. A new head of digital, a newly promoted COO, sometimes a marketing director who's had "digital" quietly added to their remit without anyone asking whether they wanted it. They call us because they've inherited a mess and they don't know where to start. And almost every single one of them opens with some version of the same sentence: "I can already see what needs fixing - I just need to get on with it."
I get it. You've got fresh eyes. The problems feel obvious. The homepage looks like it was designed during the last World Cup. The page speed score makes you wince. The navigation is a mystery even to the people who built it. You want to show early momentum, prove you were the right hire, and start making visible improvements.
But here's the thing - and I say this having watched it go wrong enough times to feel quite strongly about it - the changes that look obvious before you've done an audit frequently turn out to be wrong after it.
That outdated homepage? Might be the only page that's actually converting. The confusing navigation? Could be compensating for a broken integration that nobody documented. The slow page speed? Possibly a symptom of a hosting arrangement that's bundled into a contract with an auto-renewal clause hitting in six weeks.
The visible problems are symptoms. The causes are buried in the infrastructure, the integration architecture, and the contract and licensing structure underneath them. And if you start fixing symptoms without understanding causes, you'll spend money, burn goodwill, and quite possibly break things that were quietly working.
So before you change anything, build an accurate picture of what exists. That's the job for your first 30 days.
When we help someone audit a digital estate they've inherited, we work across six domains. Think of these as a scaffold, not a workload. You don't need to complete all six to the same depth at the same time - but you do need to know they exist, because gaps in any one of them will bite you eventually.
Platforms and hosting. Which CMS, marketing automation, analytics, CRM, and other digital platforms are in use? What version of each? Who hosts them? What's the support and licensing status? This is the foundation of every subsequent decision you'll make. I worked with a COO last year who discovered - three months into her role - that the firm was running a CMS version that had been end-of-life for two years. Nobody had flagged it because nobody was looking. She wasn't angry, exactly. More just... tired. Like she'd expected it.
Content and assets. An inventory of the content estate - pages, documents, media files, templates. You need to know the volume, the age, and a rough sense of quality. Not because you're going to read every page, but because this is what informs migration, consolidation, and improvement decisions later. One firm we assessed had 4,200 pages. About 600 were still relevant. The rest were ghosts - outdated service descriptions, event pages from 2019, PDFs linking to systems that no longer existed.
Integrations and data flows. How do the platforms connect to each other and to core business systems? Which data flows are automated, which are manual, which are broken in ways nobody's documented? This is the domain that catches people out most often. I've seen organisations where the CRM integration "worked" - in the sense that data moved from A to B - but nobody could tell you what happened to it after that, or whether it matched what was in the finance system. Technically functional. Practically useless.
Contracts and licensing. What you're paying for, to whom, when it expires, and whether the contracted scope matches what you're actually using. This domain consistently reveals waste. I mean consistently - we've never audited a digital estate and not found something the organisation was paying for that it didn't use, or something it was using that it wasn't properly licensed for.
Access and permissions. Who has admin access to which platforms? Is that access appropriate given current team membership? And - this is the one that makes people uncomfortable - do former employees or contractors still have access they shouldn't? More on this in a moment.
Documentation. What written records exist of deployment processes, integration architecture, content standards, and editorial workflows? And what lives exclusively in someone's head? The overlap between key-person dependency and documentation gaps is almost total. Almost every time.
Now, I'll be honest - these six domains don't always sit neatly apart in practice. Contracts and platforms bleed into each other constantly. Access issues often only make sense once you understand the integration architecture. So treat the framework as a starting map, not a strict filing system.
You don't have the luxury of completing a full audit before acting. Some things carry enough immediate risk that they need attention in your first two weeks.
Access and permissions. Do this on day one. Literally day one. Stale access from former employees isn't just a theoretical security risk - it's a control failure that, if something goes wrong, lands on you. Get a list of everyone with administrative access to every critical platform. Check it against your current employee list. Revoke anything that shouldn't be there.
I remember a conversation with a head of digital who'd been in post for about three weeks. She'd just discovered that a freelance developer who'd left the project eighteen months earlier still had root access to the production CMS. Nothing had gone wrong - yet. But eighteen months of unrevoked access to a production system? That's the kind of thing that keeps compliance teams awake at night, and rightly so. She told me she felt sick when she found it. Not because anything had happened, but because she'd been responsible for it for three weeks without knowing.
Contract and licensing obligations. Within your first two weeks, find out whether there are contracts approaching renewal, contracts with auto-renewal clauses you might miss, or licensing arrangements where actual use doesn't match contracted scope. Auto-renewals are the silent killer here. I've seen firms locked into another twelve months of a platform they'd already decided to replace, because nobody checked the renewal date until it was too late. That's not a technology problem. That's a diary problem.
Unsupported platform versions. Identify any platforms running on end-of-life software. Every day you don't know about these is a day your security exposure is growing. And if you're in a regulated industry - financial services, legal, healthcare - unsupported platforms aren't just a risk, they're a potential compliance violation.
These three areas can surface things that require immediate action. Content, integrations, documentation - all important, but they can wait a bit longer. Don't let the comprehensive audit delay the urgent stuff.
Here's where people get stuck. "I'm not technical enough to audit the platforms." Maybe not. But you don't need to be a developer to ask the right questions. You need to be a decent interviewer.
Four questions will get you further than you'd expect.
"Who are the two or three people in the organisation who know the most about how our digital systems work?" Start with them. They carry the institutional knowledge that documentation almost never captures. Buy them a coffee. Probably buy them lunch, actually - they've been holding things together with no recognition for longer than they'd like to admit, and they'll tell you things in a relaxed conversation that they'd never put in a formal report. In my experience, these conversations are where the real audit happens.
"What are the three things most likely to break if we make changes?" This is my favourite question because it surfaces the fragile integrations and hidden dependencies that a purely technical audit might miss. People who've lived with a system know its weak points intuitively. They'll say things like "don't touch the events page because it feeds the booking system through an API that Dave set up in 2021 and nobody else understands." That's gold. Write it down.
"What do we pay for that we don't use, and what do we use that we don't pay for?" The first half surfaces waste. The second half surfaces shadow IT - the tools and platforms that teams have adopted informally, that may carry data or security implications nobody's considered. Almost every audit we've done has found at least one tool that a team was using daily that IT didn't know about. Sometimes several.
"What have we been meaning to fix for years but haven't got to?" This surfaces the known technical debt that's accumulated under previous ownership. Fair warning: not all of it will be accurate. Some of it will be pet grievances dressed up as problems. But the patterns tell you something important about where the real pain is.
I'll add a fifth question that I've started using more recently, though I'm still not sure it always lands: "If you were me, what would you do first?" Sometimes you get a blank stare. But occasionally someone says something that reorders your entire list of priorities.
The output of all this isn't a 60-page technical report. A spreadsheet works fine, honestly. One row per significant platform. Columns for: platform name and version, vendor and support status, hosting arrangement, primary users and use cases, integrations and dependencies, contract and renewal status, documentation status, current known issues.
You could set it up in twenty minutes and populate a working draft within three to four weeks using those questions and whatever platform documentation already exists.
It won't be perfect. There'll be gaps, question marks, cells that say "unknown - need to investigate." That's fine. The point isn't completeness - it's visibility. You're building a shared picture of what exists and what needs attention. A baseline that makes every subsequent decision more reliable, because you're no longer guessing at the dependencies.
If you want the six-domain audit framework as a structured template - ready to populate as you work through the questions - download it here. For a facilitated version that covers the estate systematically and produces a prioritised findings report, book an estate review.
The audit will typically produce findings in three categories, and being disciplined about which category each finding belongs in is half the battle.
Immediate actions - security risks, access issues, and contract obligations that need addressing within the first 30 days regardless of your longer-term strategy. These aren't optional. These aren't "when we get round to it." These are the things that, if they go wrong before you've dealt with them, become your problem in a very personal way.
Quick wins - improvements that can be made without significant cost and that address known pain points. Typically in the content and user experience domain: fixing broken links, updating outdated pages, improving a confusing form. Quick wins matter because they build credibility. They show people that something is actually happening, which makes the bigger conversations easier later.
Strategic decisions - the platform, integration, and investment decisions that need proper planning, budget, and buy-in from the right people. These go into the medium-term roadmap, not the 90-day plan. If you've inherited a multi-site estate from acquisitions, for example, the consolidation decision is strategic - there's a companion piece on the digital consolidation playbook that covers that scenario in detail.
The 90-day plan should have no more than three to five items. I know that feels restrictive. You'll have a list of twenty things that need doing. But a new leader who tries to do everything in 90 days consistently does nothing well. Pick the things that will make the biggest difference to risk reduction and operational stability. Do those properly. Then reassess.
I had a conversation recently with someone who'd been in a new head of digital role for about six months. She told me that the audit she'd done in her first month was - and this is a direct quote - "the most boring and the most valuable thing I've done in this job."
She said it had saved her from at least two decisions that would have been expensive mistakes. And it had given her the credibility to push back when senior stakeholders wanted to skip straight to the shiny stuff. What she didn't say, but what I've heard versions of from other people in similar positions: knowing what you've got means you stop being reactive. You stop getting ambushed by things that were always there, just undiscovered.
That's the real payoff. When someone in the leadership team says "can't we just rebuild the website?" and you can say "here's exactly what that would involve, here's what it would cost, and here's why I'd recommend we do these three things first" - that's the moment you stop being the new person and start being the person who knows what they're talking about.
Start with access and permissions. Today, if you can. The rest will follow.