Prioritise standards support when the application is business-critical, has recurring joiner-mover-leaver activity, or would create a large compliance gap if access had to be managed manually. Custom work may solve one app, but standards reduce long-term maintenance and make lifecycle governance more scalable across the portfolio.
When standards support should outrank one-off integration work
Standards support should win when the application is not just another connector, but part of a recurring access lifecycle that must survive change, scale, and audit. If joiner-mover-leaver events, entitlement updates, or periodic recertification are common, a standard pattern usually creates more durable governance than bespoke code tied to one system version or one team’s memory.
That is especially true when the business depends on consistent access decisions across many applications, because custom integration tend to fragment behavior over time. A standards-based approach gives you a repeatable contract for identity, provisioning, and deprovisioning, which makes lifecycle control easier to operate, test, and explain to auditors and internal stakeholders.
Standards also become the better investment when the application is business-critical or sits on a control boundary. If access handling fails, the cost is not just a broken workflow, but delayed onboarding, orphaned accounts, inconsistent revocation, or manual exceptions that accumulate into governance debt. In that situation, the long-term operating model matters more than the immediate convenience of a bespoke shortcut.
Where custom integration still makes sense
Custom integration is usually justified when the system is low-value, short-lived, or technically unable to support the relevant standard without disproportionate effort. A narrow adapter can be a rational bridge for a niche workflow, a legacy platform, or a temporary migration, especially when the team can tolerate manual oversight and the access model is stable.
The key question is whether the custom path is solving a true business requirement or simply avoiding the effort to adopt a standard. If the app is one of many that will need the same lifecycle treatment, custom work creates repeat maintenance, duplicate logic, and inconsistent security behavior. If it is genuinely isolated and unlikely to recur, the bespoke option may be the more practical choice.
Custom work should also be treated as a conscious exception when it cannot introduce material access risk. If the manual process is simple, the user population is small, and the operational blast radius is limited, engineering effort may be better spent elsewhere. The decision changes when the same pattern starts appearing across the portfolio, because the integration becomes a platform concern rather than a point solution.
How to decide at portfolio level
At portfolio scale, the real trade-off is not standards versus code, but standardisation versus repeated exception handling. Standards reduce the number of unique control paths you must own, which lowers maintenance effort and makes future applications easier to onboard. That benefit compounds when multiple teams, regions, or business units need to follow the same lifecycle rules.
The decision is strongest when you can point to recurring governance obligations, such as access reviews, timely deprovisioning, or evidence retention. In those cases, standards help preserve consistency across the CIS Controls v8 style priorities of account management, access control, and logging, while also aligning with ISO/IEC 27001:2022 Information Security Management expectations for repeatable control operation. If the environment is cloud-heavy, the same logic maps cleanly to the CSA Cloud Controls Matrix focus on IAM and control consistency.
For organisations that manage many connected systems, standards also help avoid the hidden cost of bespoke trust relationships. A custom interface may work today, but every exception becomes a future dependency, and every dependency needs testing when the app, the directory, or the access policy changes. Standards are the better default when that future change is likely.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and CSA Cloud Controls Matrix set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Recurring joiner-mover-leaver handling depends on consistent account lifecycle control. |
| Recommendation — Standardise account lifecycle handling and remove ad hoc exceptions across the portfolio. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Standards support reduces inconsistency in access governance across applications. |
| Recommendation — Adopt uniform access control patterns instead of app-by-app custom handling. | ||
| CSA Cloud Controls Matrix | IAM — Identity & Access Management | The question is about scaling access governance across applications and vendors. |
| Recommendation — Use IAM standards to make provisioning and deprovisioning repeatable across systems. | ||
Practitioner Guidance
What to prioritise: Prioritise standards support first for applications with recurring joiner-mover-leaver events, shared entitlement models, or material audit exposure. Those are the cases where lifecycle control, not just integration convenience, determines whether the solution is sustainable.
Decision rule: If the same access pattern will be needed for more than one application, or if a manual fallback would create repeated operational or compliance work, treat the standards path as the baseline and custom code as the exception.
What to verify: Verify whether the application can support the standard without losing the specific lifecycle events you need, especially create, update, disable, and recertify. A “supported” integration that still requires manual cleanup is usually not a real control win.
Practitioner takeaway: Choose standards when the access problem is recurring and governable; choose custom work only when the scope is narrow enough that the exception will not become tomorrow’s control debt.
Related resources from NHI Mgmt Group
- When should organisations prioritise product infrastructure over custom feature work to support go-to-market scale?
- When should organisations prioritise an import-based transition over building a custom authorization integration?
- When should organisations prioritise consent integration over broader marketing optimization work?
- When should organisations prioritise post-quantum migration work over waiting for final standards?