ServiceNow Strategic Portfolio Management: Security and Access Design

Security and Access Control in Portfolio Management

Strategic Portfolio Management holds the organisation’s investment decisions: which projects are funded, how budgets are allocated and which priorities sit behind them, so project financials, strategic classifications and approval status need tighter control than most platform data. A project manager should see their own projects and not their peers’; an executive needs portfolio-level figures without detailed cost estimates; a finance analyst needs the financial fields but must not alter strategic classifications. The sections below build that into a role model, least-privilege rules, segregation of duties, audit evidence, a compliance review cycle, field-level sensitivity and monitoring.

Role Model for Portfolio Management

Define roles aligned to job responsibilities. Common roles: Portfolio Manager (defines strategic goals, prioritizes projects, allocates budgets); Project Manager (submits projects, updates status and budget); Finance Analyst (reviews financial accuracy, flags budget variances); Approver (executives who approve investments); and Auditor (reviews decisions for compliance). Each role has specific permissions: Portfolio Manager can view all projects and make approval decisions; Project Manager can view and edit their own projects; Finance Analyst can view financial fields but not approval status.

Use role-based access control (RBAC) in ServiceNow: create roles under user administration, then grant each role its permissions through access control rules (which tables can each role access? Create, read, update, delete?), and assign roles to users based on their job function. Avoid overly-granular roles (do not create a role for “Project Manager in Finance Department”—they should use the standard Project Manager role). Maintain fewer, well-defined roles; they are easier to audit and less likely to have gaps.

Least Privilege Principle

Each user should have only the permissions they need to do their job. A project manager needs to create and edit their own projects but should not approve investments (that is the executive’s role). A finance analyst needs to view financial data but should not mark projects as approved. Implementing least privilege: when creating a role, start with no permissions, then add only what is necessary. Review roles quarterly: are users still in the right roles? Did a promotion require a role change?

Implement read-only access where possible. An analyst who reads reports should not have write access to the data underlying the reports. A stakeholder who reviews projects should not approve them. This prevents accidental or malicious changes.

Segregation of Duties

No one person should have end-to-end control over a critical process. For portfolio approvals, separate the roles: a project manager submits a project, a finance analyst validates the budget, and an executive approves the investment. No single person should submit, validate, and approve. This prevents fraud or mistakes going undetected.

Implement SoD (Segregation of Duties) violations in your access control: define which roles cannot be held by the same person. For example, “Project Manager” and “Approver” should not be the same person (a project manager could approve their own expensive project, bypassing governance). ServiceNow can report SoD violations; review them quarterly and remediate if violations exist.

Audit Evidence and Change Tracking

Portfolio decisions are often subject to audit: why was this project approved? Who approved it? When? What was the financial justification? Design your system to capture this evidence. Use audit log fields: track who created a record, who changed it, when, and what changed. ServiceNow’s System Audit Log captures this automatically for most tables.

For critical fields (approval status, budget, classification), enable change tracking: maintain a history showing what value was changed from/to and who changed it. This creates evidence that decisions were made by authorized people using current information.

Store approval artifacts: when a project is approved, capture the approval (date, approver name, any comments). If approval requires a signature or additional justification, store it. Many organizations require formal approval sign-off (a document showing the decision and the approver). Keep these artifacts with the project record so an auditor can see the evidence.

Compliance Review Cycle

Establish a quarterly or semi-annual review: does the access control model still match your organization structure? Have roles drifted (people have permissions they no longer need)? Are there access violations (someone holds two roles that should be separated)? Use ServiceNow’s compliance reports: most GRC tools show access reports and SoD violations. Address violations quickly: either remove conflicting roles or document a waiver and the business justification.

Review approval decisions: sample a set of approved projects and verify: did an authorized approver approve them? Did the approver have the necessary information (financials, risk assessment) when deciding? If approval decisions are weak (insufficient evidence, unauthorized approvers), tighten the approval process.

Data Sensitivity and Field-Level Access

Some fields in portfolio records are sensitive: cost estimates, strategic priorities, executive comments. Use field-level security to restrict access: a project manager can see most fields of their project but not cost estimate (finance sees that). A portfolio manager can see all projects but a contractor or vendor should see only their assigned project (no competitive intelligence).

Implement in ServiceNow using table access rules and field access: define rules like “if role = vendor, and record is not assigned to this vendor, hide access”. This prevents unauthorized views while allowing necessary collaboration.

Monitoring and Alerting

Set up alerts for risky activities: when a project budget is increased significantly, alert the finance team so they can review if it is legitimate. When an approval is bypassed (workflow skipped), log it and escalate. Monitor failed access attempts: if a user tries to access a project multiple times and fails, investigate.

Create dashboards for compliance monitoring: how many projects are pending approval? Are there SoD violations? What is the status of quarterly access reviews? Use these dashboards to keep governance visible and catch issues early.

How a single request to a portfolio record is checked

A user who asks for a portfolio record has to pass several checks in sequence, and the outcome depends on all of them. The platform looks at the table, then at each field the user wants to see or change, and at any condition written against the record. A role that grants read on a table does not cancel a restriction placed on one field, because every applicable rule has to pass. Designs that think only in terms of roles miss the field-level and condition-based rules, and those are where unintended exposure usually sits.

The practical consequence is that the access matrix has to be written at three levels: which tables a persona may touch, which fields inside those tables are restricted, and which records a condition hides from them. A matrix that stops at the first level tells the owner that a project manager can read projects, which is true, and says nothing about the cost estimate on the same form.

Choosing a pattern for each kind of restriction

Most portfolio restrictions can be built in more than one way. The table below compares the four patterns that appear in practice. The right choice depends less on what is technically possible and more on who has to maintain the rule after the first designer has moved on.

Scripted rules deserve the closest review. They are sometimes added to solve a single awkward case, and the case is then forgotten while the rule keeps running on every list view. Write down the business reason beside each scripted rule and review it at the same time as the role model.

Testing access as each persona before go-live

Testing with an administrator account proves very little about access, because administrators can see records that ordinary users cannot. The test has to be run as the people who will actually use the portfolio, and the steps below give a repeatable way to do that. For the wider platform view of reviewing permissions, the access controls review post covers the administrator side.

1. Create one test user for each persona in a non-production copy of the instance, and give each user only the roles that persona should hold, with no extra roles added for convenience.
2. Sign in as each test user, or impersonate it from an account that is permitted to do so, and open a set of records that covers every business unit, every lifecycle stage and at least one closed item.
3. For each record, check which fields are visible, which are editable and which are hidden, and compare the result with the matrix the record owner signed off.
4. Run the same list views and reports as that persona. A report that totals a restricted field can show a figure the form itself hides, so this step catches a leak the form test misses.
5. Paste the direct address of a record the persona should not see. A list filter does not stop someone who already has the link, so this check is the one that shows whether the rule itself holds.
6. Log each result against the role set used, so that a later change to a role can be re-tested against the same cases rather than against a fresh set of records chosen by memory.

Where administrator and integration access hides real exposure

Two groups of account tend to escape the portfolio access design altogether. The first is the set of users with broad platform roles, such as those who can edit access rules or change system properties. A portfolio approver should never hold those roles, because the person who approves an investment should not also be able to change what they are allowed to see. The roles and RACI for portfolio work helps show which roles each approval needs. The second group is integration accounts. A service account that reads the portfolio to feed a finance or reporting tool often has wider read access than any human user, because it was set up once for a data feed and never reviewed again.

Each integration account needs its own entry in the access review, handled in the same way as any other privileged account. Record what it reads, what it writes and which downstream system receives the data. If the downstream system is less tightly controlled than the portfolio itself, the effective access to cost figures is the weaker of the two, whatever the portfolio rules say.

Access decisions to settle before the design is built

• Which fields are restricted, and who is entitled to declare a field restricted and sign that off?
• Does a vendor ever need to see a portfolio record, or only the work item that is linked to that vendor?
• Which roles may change access rules, and are those roles kept separate from the roles that approve investments?
• Which integration accounts exist today, what does each one read and write, and who reviews them?
• Which reports and dashboards are shared beyond the people who open the portfolio itself?

Is hiding a field on the form enough?

No. Hiding a field on the form changes only what people see in the default view. The same value can still appear in a list column, a related list, an export or an API response, so the protection has to sit in the access rules. Treat form layout as presentation and access rules as the control.

Should a finance analyst be able to change an approval?

Generally not. A finance analyst should review budget figures and raise a variance, but the approval status belongs to the approver. If a finance analyst needs to edit that field to do the job, the approval step is probably missing a role, and that gap should be fixed in the design rather than solved by granting edit access.

How often should the persona tests be repeated?

Repeat them after any change to roles, access rules or the portfolio data model, and before each platform upgrade. A test run once a year does not cover a configuration that changes every month, and the cases that break are often the ones added after the original test was signed off.

Does the audit trail prove that access was correct?

No. An audit trail shows what was changed and, depending on what the instance is configured to record, some of what was read. It cannot show that access was limited correctly in the first place. Use it to investigate an event, and use the persona tests to show that the design worked before the event happened. For the wider approach to reviewing permissions, see the notes on access recertification.

Next step

If access to portfolio data is unclear across roles, integrations and reports, it helps to review the design before anyone changes a rule. For the broader risk picture around these controls, the security, risk and governance page covers the wider topic.