How should organisations reevaluate their security posture during major business or infrastructure change?

Treat major change as the best trigger for a security posture review, not as an afterthought. Reassess technical controls, user behavior, and workflow friction before or during cloud migration, remote work expansion, leadership changes, mergers, compliance shifts, or infrastructure redesign. The goal is to align security actions with a moment when the organisation can actually implement them.

Why major change is the right moment to rebaseline security

Major business or infrastructure change is when security assumptions are most likely to break. New systems, new workflows, new suppliers, new access paths, and new operating rhythms can invalidate controls that looked adequate in the previous state. A posture review at this moment is useful because it focuses security work on the environment the organisation is actually moving into, not the one it is leaving behind.

That makes the review broader than a control checklist. It should cover technical exposure, operational dependencies, and the way people will actually work once the change is live. For example, cloud migration changes trust boundaries and configuration risk; remote work changes endpoint, network, and access assumptions; mergers create overlapping identities, duplicated tools, and inconsistent governance; infrastructure redesign changes segmentation, logging, and recovery expectations.

Use the change itself as the forcing function to ask three practical questions: what is now exposed, what controls no longer fit, and what new failure mode is being introduced. Organisations often wait until after go-live to discover that legacy approvals, old workflows, or inherited exceptions no longer match the new operating model.

What to reassess before, during, and after the transition

The most useful posture review examines control effectiveness in the context of the new design, not just policy compliance. Start with the parts of the stack that usually change fastest: access paths, administrative workflows, logging coverage, third-party connections, backup and recovery assumptions, and any automation that will inherit new privileges or new dependencies.

Technical controls: authentication, authorisation, segmentation, patching, monitoring, encryption, and recovery.
Human factors: role changes, remote behaviour, approval bottlenecks, training gaps, and shadow processes.
Workflow friction: where the new model will tempt users or teams to bypass controls to keep work moving.
Governance: ownership, review cadence, exception handling, and accountability for new assets or services.

This is also the point to use evidence from the environment you are moving into. If the change increases reliance on secrets, service credentials, or cloud integrations, then secret handling and access governance need review alongside architecture. NHIMG research shows how often weak practices persist in this area, with The Ultimate Guide to Non-Human Identities noting that 96% of organisations store secrets outside dedicated secrets managers and 71% do not rotate them within recommended time frames.

For cloud-heavy transformations, map the new operating model to a control baseline such as CSA Cloud Controls Matrix, which helps structure review across IAM, infrastructure, audit, data protection, and supply chain. If the change is more general enterprise security uplift, the govern, protect, detect, respond, and recover structure in NIST Cybersecurity Framework 2.0 is a practical way to ensure the reassessment does not stop at prevention controls alone.

Risk and Threat Considerations

Major change increases the chance that existing controls will be misapplied, delayed, or bypassed. The risk is not only that attackers exploit the transition, but that the organisation creates avoidable exposure by carrying forward outdated trust assumptions, unclear ownership, or temporary exceptions that become permanent.

Failure mechanism: Change introduces new assets, identities, integrations, and workflows faster than review and governance can keep pace. That can leave privilege, logging, segmentation, backup, and recovery controls misaligned with the new environment, while users and administrators create workarounds under delivery pressure.

Impact: The result can be wider blast radius, weaker detection, higher likelihood of misconfiguration, and slower recovery if an incident lands during the transition. In merged, migrated, or replatformed environments, this often shows up as duplicated access, orphaned accounts, inconsistent policy enforcement, and missed accountability.

In practice, the highest-risk transitions are the ones that combine architecture change with business urgency. Cloud migration, remote-work expansion, and merger integration all create opportunities for both control drift and adversarial abuse of temporary access paths.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	GV — Govern	Major change requires updated governance, ownership, and risk decisions.
	PR — Protect	Posture reviews must reassess controls that change with migration or redesign.
	RC — Recover	Change can weaken recovery assumptions and rollback readiness.
Recommendation — Rebaseline risk ownership and decision rights before the new operating model goes live. Revalidate protective controls against the new architecture and workflow model. Test recovery and rollback paths against the redesigned environment.
CIS Controls v8	5 — Account Management	Major change often creates new, duplicated, or orphaned access paths.
	8 — Audit Log Management	Logging coverage often breaks during migration or redesign.
	4 — Secure Configuration of Enterprise Assets and Software	Infrastructure change commonly introduces misconfiguration risk.
Recommendation — Review accounts and access paths created or inherited during the transition. Verify logs still capture the events that matter in the new environment. Recheck secure baselines after architecture or platform changes.
NIST Zero Trust (SP 800-207)	3 — ZTA Logical Components and Policy Engine	Major change often alters trust boundaries and policy enforcement points.
Recommendation — Reassess trust boundaries and policy decisions after the environment changes.
OWASP Non-Human Identity Top 10	NHI-01 — Secrets and Credential Management	Change can expose secrets handling gaps when new integrations or automation appear.
	NHI-03 — Lifecycle and Offboarding	Mergers and restructures often leave stale identities and access behind.
	NHI-04 — Least Privilege and Authorization	New workflows often expand privilege beyond what the redesign needs.
Recommendation — Rotate and inventory secrets that gain new reach in the changed environment. Retire obsolete identities and access paths created by the transition. Rework authorisation so new access matches the post-change business need.

Practitioner Guidance

What to prioritise: Review the controls that will change behaviour immediately, especially access, logging, approvals, and recovery. If a control cannot be operated cleanly in the new model, fix the operating model rather than assuming users will tolerate friction indefinitely.

What to verify: Confirm that every material change has an owner, a rollback path, and an explicit decision on what becomes more permissive, what becomes more restrictive, and what must be retired. If the answer is “temporary exception,” set an expiry and an approver before go-live.

Practitioner takeaway: The best posture review is timed to the moment the organisation can still shape the new normal, because after the change settles, weak assumptions are harder to spot and much harder to unwind.