TL;DR: Nexis says teams can create and manage their own compliance requirements and regulations directly in the UI, then attach controls, questions and descriptions so they appear in the Compliance module and support maturity assessments. The governance challenge is less about building a catalogue and more about keeping custom controls consistent, reviewable and auditable alongside standard frameworks.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Nexis's event briefing: Teams can define custom compliance requirements in the UI, attach controls and questions, and use them in the Compliance module for maturity assessments.
Why it matters: For IAM and GRC practitioners, the issue is governance discipline: custom requirements are only useful if they remain consistent, reviewable and tied to assessment evidence instead of becoming a parallel control library.
👉 Read Nexis's session on building custom compliance frameworks in the UI
Context
Many compliance programmes struggle because custom requirements live outside the same place as standard controls, which makes assessment, review and evidence handling inconsistent. When teams have to move between a separate data entry tool and the system where maturity is measured, the control model becomes harder to govern than the compliance issue itself.
The practical question is how to let teams define their own requirements without breaking the structure that makes assessments usable. A controlled in-product workflow can reduce friction, but only if the organisation still treats custom controls as governed artefacts rather than local workarounds.
Key questions
Q: How do teams govern custom compliance requirements without creating control sprawl?
A: Teams govern custom compliance requirements by mapping each requirement to a named control owner, a clear control objective, and a standard evidence test. They avoid control sprawl by reusing a common control library, tagging exceptions separately, and reviewing overlaps during risk and audit cycles so duplicate controls are retired or merged.
Q: When should organisations separate custom requirements from standard catalogues?
A: Organisations should separate custom requirements from standard catalogues when a rule is unique to one regulatory obligation, client contract, or risk exception and does not fit a reusable baseline control. Standard catalogues should hold common controls, while custom items stay separately tagged so they do not distort assessment results or duplicate evidence requests.
Q: What is the best way to keep compliance evidence auditable as frameworks change?
A: The best way to keep compliance evidence auditable as frameworks change is to store evidence against control objectives, not just framework labels, and maintain traceability from each requirement to the underlying artefact. Version control, immutable timestamps, and a controlled mapping between old and new frameworks preserve continuity when controls are renamed or reorganised.
Background and context
How custom controls fit into a compliance catalogue
A custom compliance framework extends the catalogue a platform already uses for standard requirements. Instead of forcing teams to manage requirements in a disconnected spreadsheet or external tool, the UI becomes the place where controls, prompts and descriptions are structured into the same assessment model. The important mechanism is not simply storage. It is normalisation, so custom items behave like other governance objects and can be measured, assigned and reused consistently across assessments.
Practical implication: Model custom requirements as governed records with the same lifecycle discipline you apply to standard control libraries.
Why control descriptions and questions matter for maturity assessments
A maturity assessment only works when the control intent is clear enough to evaluate consistently. Questions and descriptions give assessors the context they need to interpret whether a requirement is met, partially met or missing. Without that structure, custom controls become ambiguous and assessments drift toward subjective scoring. In practice, the quality of the description determines whether the control can be audited, benchmarked and compared over time.
Practical implication: Write custom control text so reviewers can assess it the same way every time, without relying on tribal knowledge.
How to avoid a parallel compliance library
The main governance risk is not feature complexity, but duplication. If custom requirements are added without ownership, review cadence and version control, the organisation ends up with a second control universe that is hard to reconcile with standard catalogues. That creates gaps in reporting, evidence collection and accountability. A single compliance module only helps when custom and standard requirements are governed under the same operating model.
Practical implication: Assign ownership and review rules to custom controls before they are used in assessments or reporting.
NHI Mgmt Group analysis
Custom compliance content is a governance object, not just a configuration choice. The moment teams create their own requirements, they inherit a responsibility to define ownership, review cadence and assessment consistency. If those controls are treated as local shortcuts, the programme gains flexibility but loses comparability. The right lens is not whether users can add controls, but whether the organisation can still trust the resulting maturity picture.
Embedding custom requirements in the same module as standard catalogues reduces process friction, but not governance debt. A shared interface makes it easier to assess bespoke controls alongside established ones, which is operationally useful for mixed IAM and GRC programmes. But the value depends on whether the organisation can distinguish controlled variation from uncontrolled drift. Without that distinction, custom frameworks become an evidence management problem, not a compliance capability.
Flexible control design exposes the quality of the underlying compliance model. If the organisation cannot describe a custom control precisely enough to attach questions and measure maturity, then the issue is not tool support but control design maturity. That is why custom frameworks should be treated as governed artefacts with the same discipline applied to standard catalogues. Framework governance matters because assessment quality depends on structure before it depends on scale.
Named concept: compliance control sprawl. When every team can create its own requirements without a common governance model, the catalogue expands faster than the programme can reconcile it. The result is fragmented evidence, inconsistent scoring and weaker auditability across the compliance module. Practitioners should treat custom control creation as a governed exception, not a default operating pattern.
What this signals
Compliance control sprawl: custom frameworks are useful only when the organisation can preserve a single governed source of truth for assessment logic. If local teams can add requirements without lifecycle discipline, maturity scoring quickly becomes inconsistent across programmes.
For IAM and GRC teams, the deeper signal is that governance tooling is moving toward in-product configuration, but process control still has to be designed outside the interface. The platform can hold the controls; the organisation still has to hold the policy.
For practitioners
- Define ownership for custom controls Assign a named owner, reviewer and approval path to every custom requirement before it enters assessment use.
- Standardise control descriptions Write each control description and question set so different assessors can score it consistently without interpretation gaps.
- Separate local flexibility from governed change Use a formal change process for additions, edits and retirements so the compliance catalogue stays auditable over time.
- Check reporting before scale-out Validate that custom requirements appear cleanly in the Compliance module and roll into maturity reporting without manual rework.
Key takeaways
- Custom compliance frameworks create value only when they are governed as first-class compliance objects rather than local shortcuts.
- The operational benefit is faster assessment design, but the governance cost is control sprawl if ownership and review are weak.
- Maturity reporting remains trustworthy only when custom requirements are versioned, comparable and tied to a single control model.
Related NHI Mgmt Group resources: Regulations and Frameworks Guide · GRC Platform Buyer's Guide · Compliance Automation Buyer's Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.PO-01 — Policies, Processes and Procedures | Custom compliance requirements need governance rules, ownership and review processes to stay usable. |
| GV.OV-01 — Oversight of the Cybersecurity Program | Custom frameworks affect how maturity is measured and overseen across the programme. | |
| ID.IM-01 — Improvements | Custom requirements are part of continuous improvement when the compliance model evolves. | |
| Recommendation — Define policy and process rules for custom controls before they enter the assessment workflow. Review custom controls under programme oversight so scoring remains consistent and auditable. Track changes to custom controls as part of an improvement cycle with documented ownership. | ||
| CSA Cloud Controls Matrix | GRC — Governance, Risk and Compliance | The topic is centred on designing and governing compliance requirements in a GRC workflow. |
| Recommendation — Use GRC governance practices to version, approve and monitor custom compliance requirements. | ||
Key terms
- Compliance Control Sprawl: Compliance control sprawl is the uncontrolled growth of overlapping, duplicated, or one-off compliance controls across frameworks, teams, or audits. It usually appears when requirements are added without rationalisation, making control ownership, evidence collection, and maturity scoring harder to manage consistently.
- Maturity Assessment: A maturity assessment is a point-in-time evaluation of how well a cybersecurity program is operating against a defined framework or set of expectations. It is used to benchmark current practices, communicate status to executives, and guide roadmap planning. It does not replace continuous risk management or day-to-day control monitoring.
- Control Catalog: A control catalog is a defined list of security controls that organisations can implement and assess directly. Unlike higher-level governance frameworks, a control catalog translates risk into concrete technical and operational requirements, such as account management, logging, authentication, and monitoring.
- Governance Workflow: A governance workflow is the controlled sequence used to approve, record, and resolve changes to a governed asset. It turns policy into an auditable process by linking ownership, decision-making, and change history so that accountability can be verified after the fact.
What to expect at the briefing
Nexis's full event briefing covers the operational detail this post intentionally leaves for the source:
- Live walkthrough of creating custom requirements directly in the UI
- How questions and descriptions are attached to new controls
- Where custom requirements appear inside the Compliance module
- How those controls feed maturity assessments
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on November 5, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org