ServiceNow Demand Management: Security and Access Design

Demand Management Security Context

Demand management handles project prioritization and resource allocation—critical information: which projects get budget, which get deferred, who gets assigned where. Access must be controlled: project managers see their projects and team assignments, executives see portfolio and priority, demand planners influence prioritization, but do not make final decisions. Inappropriate access can lead to data manipulation, favoritism, or critical projects being postponed without authorization.

Role Model and Access Levels

Demand Contributor: creates project requests, views status of their own requests, cannot see other requests or influence prioritization. Scope: own requests only.

Business Analyst: all of Contributor plus views requests in their portfolio/department, can evaluate business value and impact, recommends priority. Cannot approve or change final decisions. Scope: assigned portfolio or business unit requests.

Demand Planner: views all requests, analyzes portfolio, recommends prioritization order based on value, risk, resource constraints. Reviews forecasts and capacity planning. Cannot unilaterally approve; recommends to Steering Committee. Scope: all requests, portfolio-level visibility.

Steering Committee Member: reviews demand planner recommendations, makes final priority decisions, approves major changes to portfolio. Cannot directly edit requests or create priorities; can only approve planner recommendations or override with documented reason. Scope: portfolio decisions and approval authority.

Demand Manager: all of Planner plus can approve prioritization recommendations, manage the demand process, update business rules for portfolio governance. Cannot commit budget or resources; that is finance and operations authority. Scope: demand governance and process administration.

Administrator: complete system access, can modify demand rules, security settings, fields. Scope: system-wide, requires approval for sensitive changes.

Segregation of Duties

Prevent conflicts of interest: a manager should not be able to create a project, evaluate it, prioritize it, and approve it all themselves. Separate:

Data Visibility and Field-Level Access

Not all demand managers need to see financial data (estimated cost, budget allocated). Contributors do not need to see competing projects. Analysts in one business unit do not need to see strategic projects from executive-only portfolio.

Implement field-level access control: Contributors can only see their own projects and certain fields (status, description, expected benefits). Business Analysts see more fields (resource estimates, priority recommendations) but not financial details or competing projects. Planners and Steering Committee see full details. This limits accidental information leakage and keeps focus appropriate to role.

Portfolio Segregation

Some organizations have multiple portfolios (operational projects, strategic initiatives, infrastructure, security). Analysts might be responsible for only their portfolio. Steering Committee sees all. Implement role-based portfolio assignment: analyst assigned to “operations portfolio” only sees operations projects, cannot access strategic projects.

Request Modification and Change Control

After a project request is created and entered demand process, changes should be controlled. Business Analyst should not be able to change estimated cost to artificially inflate priority. Implement workflow: after request is submitted, only Demand Planner or Steering Committee can change priority, estimated cost, or resource request. Business Analyst can update description or status for their own projects only.

Audit Evidence and Logging

Log all demand decisions: who changed priority, from what to what, when, reason. ServiceNow audit log tracks these automatically. Review monthly: verify that priorities are being set through proper governance, no unauthorized changes, no conflicts of interest. If a manager frequently changes their own project priority or a planner overrides steering committee decisions repeatedly, investigate.

Review Cycle and Access Recertification

Quarterly, demand manager reviews user access: who has Steering Committee role, who has Planner role. Has anyone left the organization or changed jobs? Remove access immediately upon role change. Remove Steering Committee members who are no longer executives. Add new analysts to appropriate portfolios as they join.

Approval and Escalation

Define escalation path: if request is urgent but does not meet standard criteria for approval, who can approve exception? Typically: Demand Manager can approve urgent requests below certain value (e.g., under 500k spend). Higher values require Steering Committee or CFO approval. Document exceptions for audit trail.

Access design starts with what each person must not be able to change

Security reviews of demand management tend to start with who can log in and which menus they see. That is necessary, but the control that matters most in a demand process is narrower: which fields and which decisions each person can change. A requester who can edit the priority field after submission, a planner who can alter the sponsor on a demand already ranked, or a reader who can export the full financial detail of every portfolio item has access that the process does not intend. Begin the access design by listing, for each role, the fields it may read, the fields it may write and the transitions it may trigger. Then check that the permissions in the tool match that list, rather than inferring the permissions from the role name.

The reader is the ServiceNow security or platform owner, working with the demand governance lead, who must design the access model before the process is opened to users. It also suits the internal auditor who needs to understand what the model is meant to prevent.

Persona-level access for a demand process

The table describes access in terms of what each persona should see and what it must never change. It is a design aid: the actual roles in your instance will need their own names and may split these personas differently.

The last row needs care. Read-only roles are often given a broad view because it is convenient for reporting, and the broad view then exposes financial detail or named individual assessments that were meant for the forum alone. Build a reporting role that sees aggregates by default and requires a specific reason to open individual records.

Sequence for building and testing the access model

Access problems are cheapest to fix before users are involved. Work through the following steps in order.

1. Write the persona table for your organization, with the fields each persona may read and write, and get the governance owner to approve it.
2. Map each persona to a role in the tool, and record any persona that needs two roles, with the reason.
3. Check whether the default access granted by the platform for each role exceeds the persona table, and list every difference.
4. Restrict the differences using field-level and record-level controls, testing each restriction with a test user who holds only that role.
5. Test the negative cases: attempt each forbidden change with each persona and confirm it fails and is logged.
6. Document the tested result so that the access model can be re-tested after any change to roles or to the process.

Protecting financial and sponsor-sensitive fields

Financial fields and individual assessments are the most sensitive content in a demand process. Two practices help. The first is to keep cost figures in a separate, restricted field group rather than mixing them with the general description, so that a reader who needs the narrative does not automatically see the numbers. The second is to decide in advance which people may see an individual score and which may see only the ranked outcome. Where a score is shared with a sponsor, consider whether they need the score or only the reason for the decision, because the score can be read as a verdict on their judgment and invite argument rather than information.

Leavers, contractors and temporary cover

Access tends to outlive the reason for it. Contractors who joined to help with an intake redesign can keep planner access long after the work ends, and a sponsor who has left can remain listed as the owner of open demands. Set a deactivation route for leavers that reassigns their open demands to a named successor before access is removed, and give contractors an access end date at the point of grant. For temporary cover, use a delegation that is time-bound and recorded, so that the audit trail shows who acted under whose authority.

Questions about access in demand management

Should administrators be able to approve demands?

No. Administrators maintain configuration and should be unable to make the business decisions the configuration supports. If an administrator must sometimes act as an approver in an emergency, use a break-glass process with its own log and a review the next working day.

How often should access be recertified?

Often enough that a leaver cannot keep access unnoticed for long. Set a recertification interval the governance owner can defend, and make the reviewer someone other than the person whose access is being reviewed.

Do we need separate portfolios for different business units?

Only where the data itself must be kept apart, for example where units are legally separate or where one unit’s pipeline is confidential. Where they are not, a single portfolio with restricted views is easier to govern and report on.

What evidence will an auditor expect?

The persona table as approved, the role mapping, the test results for the restrictions, the change log of role and permission changes, and a recent recertification record. Keep these together so that the evidence can be produced without rebuilding it.

Review the access model with the team

The roles, responsibilities and RACI page covers the decision conflicts that the access model must reflect, and the testing and acceptance checklist shows where negative access tests belong in the wider test plan.