What should security teams do first when applications are added across business units?

Where to start when applications spread across business units

The first job is not to choose a new control model, it is to find the one already operating in practice. Security teams need a current map of where authentication, entitlement checks, role assignment, and exception handling are enforced today, because business units often inherit different patterns from different platforms, regions, or delivery teams.

That map should include the systems that act as the source of truth, the local tools that shadow them, and any manual workarounds that have become de facto policy. The goal is to understand whether the enterprise has one access model with many implementations, or many access models that only appear unified.

How to spot gaps before they become permanent silos

The useful comparison is not between applications in the abstract, but between control paths. A new application becomes a governance problem when it introduces a separate identity store, a separate approval flow, or a separate entitlement standard that no longer aligns with the central model. That is where drift starts, and it is why teams should inspect onboarding, provisioning, and exception paths early.

Business-unit autonomy is not inherently the issue. The risk appears when local convenience hardens into architecture, especially when teams bypass central identity and authorization to move faster. If the central model cannot describe how access is granted, reviewed, and revoked for the new application, the organization does not yet control it.

What good coordination looks like in practice

Security teams should treat the first discovery pass as a boundary-setting exercise, not a compliance review. They need to classify which applications must inherit the enterprise model, which may use an approved local pattern, and which require a bridge because a regional or business-specific tool already exists. That judgment is easier when teams document control ownership alongside application ownership.

In cloud and platform-heavy environments, the same pattern often shows up in different ways, so a broader control baseline can help compare inconsistent implementations. A cloud control reference such as the CSA Cloud Controls Matrix is useful when teams need a common language for IAM and governance across multiple delivery groups. For enterprise control mapping, NIST SP 800-53 Rev 5 Security and Privacy Controls helps anchor that review in explicit access control and identity requirements.

For teams that want a broader operating view, the NIST Cybersecurity Framework 2.0 is a practical reminder that this is a governance and lifecycle issue, not just a technical configuration task. The right question is whether the organization can consistently govern access across growth, not whether each unit can make its own stack work.

Risk and Threat Considerations

When applications are added faster than identity and authorization can be reconciled, the main risk is silent fragmentation. Separate approval paths, duplicated role models, and local exceptions can create overprivileged access, delayed revocation, and inconsistent audit evidence, especially after reorganizations or mergers.

Failure mechanism: New business-unit systems bypass the central model, then accumulate local entitlements and exception handling that are never folded back into the enterprise governance process.

Impact: Teams lose visibility into who can access what, revocation becomes slower and less reliable, and the organization inherits multiple access standards that are difficult to govern or unwind.

Practitioner Guidance

What to verify: Before trusting the environment, verify that every new application can be traced to an owning identity source, an approval path, and a revocation path. If any of those three are missing, treat the application as an unmanaged access island until it is remediated.

Decision rule: If a local tool is necessary for speed, allow it only when it still reports into the central model for review, logging, and removal. If it cannot, require an exception with an explicit retirement date or integration plan rather than allowing it to become permanent by default.

Practitioner takeaway: The first control objective is not standardisation for its own sake, it is preventing new applications from creating separate access authorities that the enterprise cannot later see, compare, or revoke.

Related resources from NHI Mgmt Group

• How should security teams make NHI best practices usable across the business?
• What should security teams do first when they cannot reliably see where sensitive data and identities are spread across business units or partners?
• How should security teams govern access across SAP and business applications?
• How should security teams implement segregation of duties across multiple business applications?