What should security leaders prioritise first when they inherit an unfamiliar organisation?

Start by understanding the organisation before you touch the control stack

The first priority is not a tool purchase, policy rewrite, or control-gap spreadsheet. It is to understand how the business actually works: how it makes money, where it depends on speed or uptime, what is customer-facing, what is regulated, and which systems or teams carry the most operational friction. That context determines whether a control is genuinely protective or simply disruptive.

A security leader who inherits a new organisation should quickly map the operating model, critical services, and the trust boundaries that matter most. A retail platform, a regulated financial business, and a software company may all need strong security, but the threats, tolerance for change, and acceptable response times are very different. That is why context comes before standardisation.

The same discipline helps avoid importing a security model that fits another company but not this one. A framework can be sound and still fail if it assumes the wrong production cadence, ownership model, or dependency profile. The goal in the first phase is to build enough situational awareness to know where security will have the biggest effect with the least unnecessary business disruption.

Turn context into a short list of material risks

Once the business model is understood, the next step is to identify the threats that matter most in that environment and tie them to the assets and workflows that would be most costly to lose, misuse, or delay. That usually means focusing on a few high-value paths first: customer data, revenue-generating systems, privileged access, third-party dependencies, and recovery-critical services.

This is where prioritisation becomes practical. Rather than asking for every control to be improved at once, leaders should separate systemic risk from background noise and decide which exposures deserve immediate attention. The early objective is to reduce the organisation’s most consequential attack paths, visibility gaps, and failure points, not to create a perfect inventory on day one.

That also means treating quick wins carefully. Some low-effort changes are worth doing early because they reduce blast radius or improve detection without heavy change management. Others look easy but can create hidden operational cost if they are applied blindly. A good first-quarter plan focuses on changes that are reversible, measurable, and aligned with the business’s tolerance for disruption.

Build the first-quarter plan around safe change, not broad ambition

The first quarter should be used to establish control over the riskiest parts of the environment while learning how the organisation responds to security change. That typically means choosing a limited number of high-value improvements, validating ownership, and proving that security can move the business forward without breaking key workflows.

For some organisations, that will mean tightening privileged access, improving asset visibility, or stabilising incident response paths. For others, it may mean addressing weak configuration practices, raising logging quality, or clarifying who approves exceptions. The common thread is that the first changes should be tied to clearly understood business dependencies, so the leader can show value without overcommitting the organisation to a large redesign.

Good security leadership at this stage is measured by sequencing. If a change is important but depends on unclear ownership, poor asset knowledge, or unresolved business trade-offs, it should usually be staged rather than forced. The first quarter is about establishing credibility, finding leverage, and proving that security decisions can be based on how the organisation really operates.

Practitioner Guidance

What to prioritise: Start with business context, then identify the few systems, workflows, and dependencies where a failure would create the largest security or operational impact. That gives you a defensible basis for choosing where to spend time first.

What to verify: Confirm who owns the critical services, how exceptions are approved, and where the organisation is most sensitive to downtime, access friction, or change resistance. If you cannot describe those points clearly, your prioritisation is still premature.

Common mistake: Do not begin by copying a previous employer’s security programme or by trying to standardise everything in the first 90 days. The right first move is to learn where this organisation is exposed, then sequence change around that reality.

Practitioner takeaway: The best first priority is not “more security”, it is accurate context that lets you choose the right security changes, in the right order, with the least business disruption.

Related resources from NHI Mgmt Group

• How should security teams prioritise NHI remediation in cloud environments?
• Should organisations prioritise external exposure or internal credential governance first?
• What should K-12 leaders prioritize first if they cannot fund a large security program?
• What should security leaders prioritise first when moving from trust but verify to continuous verification?