ServiceNow Service Mapping: Security and Access Design

Service Mapping access should be role-based, so each person sees the part of the model they need without being able to break the rest. Typical roles include service designer, incident manager, change manager, security lead, service owner and business leader. Give read-only access to anyone who only needs visibility, and keep an audit trail of every change.

Role Model for Service Mapping

Service Mapping requires a role-based access model that gives people visibility into the information they need without exposing sensitive infrastructure details. A typical model includes: Service Designer (can create and modify services and components), Incident Manager (can view services and relationships during incident response), Change Manager (can view services to assess change impact), Security Lead (can audit access and changes), Service Owner (can view their own services and approve changes), and Business Leader (can view service health and dependencies).

Each role gets access to different views and data. Incident Managers see the full dependency model so they can assess impact. Service Owners see only their services. Security leads can audit but not modify. This prevents accidental damage and ensures each person sees what they need without being able to break things they should not touch.

Least Privilege in Practice

Grant people access to the services and components they work with, not the entire model. A database administrator working on financial systems needs access to financial service components, not the entire infrastructure model. A network engineer needs visibility into network-dependent services, not every service.

Create read-only roles for people who need visibility but should not make changes. Incident responders need to see Service Mapping during incidents but should not modify it. Create roles that separate read access from write access.

Segregation of Duties

Service Designers should not be the only people who can modify Service Mapping. Require approval from Service Owners before major changes. Require Service Designers to document the reason for changes. This prevents one person from breaking the model through misconfiguration or accidentally.

Change records should trace back to who authorized them and who implemented them. Maintain audit evidence showing the chain of approval.

Audit Trail and Evidence

Maintain detailed audit logs of all Service Mapping changes: who modified what, when, what changed, what was the reason. Use these logs to investigate if the map gets corrupted or if incidents occurred because the map was inaccurate. Over time, audit trails help you understand how the service model evolved and identify patterns of problems.

Store evidence of approval for major changes. If a service map change requires Service Owner approval, keep records of that approval. This is important for compliance and for investigating if a change caused problems.

Review Cycle for Service Mapping Access

Quarterly, audit Service Mapping access. Verify that people still need the access they have. Remove access when people change roles. Identify any access anomalies: people with more access than their role should have, roles with access they should not have. Regular review prevents access creep and catches misconfigurations early.

Annual review with Service Owners to confirm that each service is still owned by the right person and that dependencies are accurate. This annual review serves double duty: it keeps the model current and it ensures access control is still appropriate.

Data Sensitivity in Service Mapping

Service Mapping may reveal sensitive information about your infrastructure: which systems handle payment data, which store customer information, architecture details that could be exploited. Restrict access to Service Mapping accordingly. Not everyone in IT needs to see the complete map. Use role-based views to show only relevant portions.

Integration With Change Management Security

When Service Mapping connects to change management, access to Service Mapping affects change approval decisions. Ensure access control is tight. A person who can modify Service Mapping improperly could influence change impact assessment. Require Service Designers to be separate from the change approval chain when possible.

Compliance and Audit Requirements

If your organization is regulated (financial, healthcare, critical infrastructure), Service Mapping likely involves compliance-relevant data. Audit teams may need visibility into the change history to verify that infrastructure changes were approved and tracked. Build audit capability into your access design: maintain logs, preserve evidence, and make audit access available to compliance teams.

The accounts behind the map are a bigger exposure than the people viewing it

Access reviews for service mapping tend to focus on the human users who open the topology. The accounts that feed the map deserve more scrutiny, because they often hold the widest rights in the estate. A discovery credential needs to log into servers. An integration account needs to read from a monitoring platform and write into the model. Each of these is often created for a single project and then left running, sometimes with a password shared among the team that set it up. If one of them is compromised, the attacker learns the topology and may gain a foothold, which is a far worse outcome than a user seeing a diagram they should not have seen.

The table below sets out the account types that appear in a typical mapping design, with the privileges each one should hold. The point is to make the scope of each account explicit, so that a reviewer can see when one has quietly grown.

Testing that access is denied, not just documented as denied

A role design that has never been tested for refusal is an assumption. Build a short set of negative tests and run them after every change to the security model. Each test should attempt something the role must not do and record the result. A test that only confirms the permitted actions still work does not show that the boundary holds.

1. Sign in as a service-owner test identity and attempt to edit a service owned by a different team. The attempt must fail and be logged.
2. Sign in as a read-only incident responder and attempt to change a relationship, including through an import or a bulk action.
3. Run the integration account against a record outside its published scope and confirm it is not returned.
4. Check that a credential rotated for discovery is not still accepted by an older scanner or a cached connection.
5. Confirm the audit record for each failed attempt names the identity and the attempted action, so the test result can be shown to a reviewer later.

Topology is sensitive as a map, even when each item is ordinary

A list of server names is one kind of information. A diagram showing which services depend on which databases, and which of those databases hold payment or health data, is a different kind. Treat exports, screenshots and shared slides with the same care as the live view. A common lapse is a dependency diagram pasted into a change ticket that is visible to a much wider group than the change itself. Set a rule that exports carry a classification, and that a diagram leaving the mapping team is reviewed for the components it reveals.

Contractors and offshore teams in the access model

Teams that supplement their staff with contractors or offshore engineers often grant them the same mapping access as internal staff, because the work is shared. Separate the question of who needs to see the map from the question of who needs to edit it. An offshore engineer doing a relationship clean-up may need edit rights on one cluster for a fixed period. Grant that as a time-bound role with the cluster named, and remove it at the end of the piece of work, rather than adding a standing role that outlives the task.

Questions about access design that come up in reviews

Can a discovery account be shared between two scanners?

It is better not to. Shared accounts make it impossible to tell which scanner performed an action, and a password change then breaks both at once. Give each scanner its own account with the same narrow scope.

Should the security lead have edit rights on the map?

No. The security lead needs to see the access model and the logs, and to approve exceptions. Editing the map is an operational duty, and combining it with the review function removes the independent check that makes the review worth doing.

What is the minimum evidence to show an auditor?

The role model as it stood on a given date, the list of accounts holding each role, the record of the last negative tests, and the change records for any role that was widened. An auditor will often ask for the widening records first, because that is where control failures are often found.

Does the map need its own encryption rules?

The map lives on the platform alongside other configuration data, so it inherits the platform’s controls. What it adds is a reason to protect exports and copies outside the platform, which is where many leaks occur.

The guide to discovery credential governance, the note on access recertification and the guide to identity integration boundaries cover the neighboring controls.