OBLYTECH Logo
OBLYTECH Logo
ServiceNow Software Asset Management Professional: Security and Access Design
Home / Guides, Services and Solutions / IT Asset Management: Guides and Services / Software Asset Management Professional: Guides and Services / ServiceNow Software Asset Management Professional: Security and Access Design

ServiceNow Software Asset Management Professional: Security and Access Design

Role-Based Access Control for SAM

Software Asset Management handles sensitive data: license agreements, pricing information, software inventory for security evaluation. Not everyone should access everything. Design role-based access that lets people do their jobs without exposing sensitive information.

Define SAM roles around the base user role, which can see the license position and reports. SAM Administrator can manage licenses and configuration. SAM Approver can approve exceptions to licensing rules. Finance can see cost reports. Procurement can see vendor agreements. Security can see software inventory for vulnerability assessment. Each role gets access only to information they need.

Implement table-level access controls. If a procurement person should not see license costs, use ACLs to hide cost fields from their view. If operations should not see vendor pricing, hide pricing from their view. Do not rely on users knowing what not to look at; use system controls.

Least Privilege and Segregation of Duties

The principle of least privilege means giving access only to what is needed. A procurement person needs to see license agreements and vendor information, not license assignments to individuals. An IT operations person needs to see what software is installed, not pricing information. Segregate access accordingly.

Segregation of duties means splitting responsibilities so one person cannot complete fraud alone. The person who adds new licenses should not be the person who approves license purchases. The person who removes software from compliance should not be the person who reports compliance status. Design workflows that require multiple approvals where financial stakes are high.

For sensitive operations, require dual control. To change a license agreement or approve a major exception, require approval from both SAM administrator and SAM lead. This prevents mistakes and provides audit trail of decisions.

Data Protection and Audit Trail

Enable audit logging for all SAM activities. When someone views a license agreement, modifies license assignment, or approves an exception, log it. Audit logs show who did what and when, essential for proving SAM integrity if auditors question your license position.

Protect sensitive data in transit. If SAM exchanges license data with procurement systems or finance systems, use encrypted connections. Do not send license data via email or unencrypted channels where it could be intercepted.

Classify SAM data by sensitivity. License pricing is sensitive (competitors want to know what you pay). Software inventory can be sensitive (shows your infrastructure footprint). License agreements contain legal terms (confidential). Classify data and apply appropriate protection levels.

Review Cycle and Access Governance

Conduct quarterly access reviews. For each user with SAM access, verify their access is still needed and appropriate for their current role. Remove access when people change jobs or leave the organisation. Document reviews for audit trail.

Review privilege escalation. Who has administrator access to SAM? Periodically verify this list is still correct. If SAM administrators leave, revoke their access immediately.

Monitor access patterns. If someone from procurement starts accessing license agreements they should not see, investigate whether access is correct or whether they are browsing inappropriately. Use audit logs to detect suspicious activity.

Exception Handling and Emergency Access

Define process for emergency access. If SAM administrator is unavailable and urgent action is needed (license renewal deadline approaching, compliance issue escalated by audit), who has authority to act? Designate a backup with elevated access and defined emergency procedures.

Emergency access should be time-limited. If someone gets elevated access for an emergency, revoke it once the emergency is resolved. Do not leave elevated access permanent because an emergency required it.

Document all exceptions. When someone is given access they would not normally have, record the business reason, who authorised it, and when it expires. This prevents “just this once” exceptions from becoming permanent.

Compliance Considerations

Compliance auditors will ask how you control access to SAM and evidence that controls are working. Be prepared to show ACL configuration, role assignments, audit logs, and access review documentation. Lack of visible controls is a compliance gap.

If you handle regulated software or have industry-specific compliance requirements, consult with compliance team to design appropriate access controls. Some industries require specific audit trails or approval workflows for license changes.

The accounts that move SAM data are a bigger risk than the people who log in

When a security architect reviews a SAM Professional design, the attention often goes to the people with interactive access: who can open the license records, who can change an entitlement, who can see the pricing. Those questions matter. In many estates, though, the larger exposure sits with the non-human accounts. A discovery credential that can reach every device, a reconciliation job running under an administrator’s identity, and an integration user created for a one-off import that never got retired can each read or change far more than any individual analyst. Designing SAM access well means treating those accounts as first-class identities with their own scope, owner and lifecycle.

This part is for the security architect and the platform administrator who need to tighten a design that already exists, or who are setting one up before the first feed goes live. It deals with service accounts, data classes and the outbound routes that carry SAM data out of the platform, which are the parts most designs leave vague.

Classifying SAM data before deciding who may read it

Access rules are easier to set once each category of SAM data has a sensitivity level and a set of legitimate readers. The table below is a working classification. The levels are relative, and the readers column describes the legitimate purpose rather than a named role, because roles change and purposes do not.

Data category Why it is sensitive Legitimate readers Route that needs the most control
Installed software per device Reveals the estate and its weaknesses Operations, security and the licensing team Scheduled exports to tools outside the platform
Contract prices and discounts Gives negotiating position away if seen outside procurement Procurement and finance Report distribution lists that include wider groups
Agreement text and clauses Confidential legal terms Legal, procurement and the licensing lead Attachments copied to records with broader read access
Named users per product Personal data about employees Licensing team, with a documented purpose Dashboards shared to audiences without the purpose
Reclamation decisions and exceptions Records of disputes and approvals Decision owners and auditors Comment threads visible to requesters

Service accounts that read or write SAM data

Every automated path into or out of SAM runs under an identity. Treat each of those identities as a separate design item with four properties written down: the owner, the single purpose, the minimum set of roles, and the credential rotation rule. An account used for discovery should be able to write installation records and nothing else. A reconciliation job should be able to read the data it compares and write only its result. An outbound report account should not be able to edit the records it reports on.

A common mistake is reusing an administrator account for convenience. It makes every automated action look like a human decision in the audit trail, and it means a compromised script can change entitlements. Separate the accounts early, because splitting an account later means reconstructing which job did what over a period nobody has examined.

  1. List every automated job, feed and report that touches SAM records, including ones built before the current team arrived.
  2. Assign each one a dedicated identity with a named owner and a single stated purpose.
  3. Grant only the roles that the purpose needs, and remove any inherited administrator role.
  4. Store credentials in the approved secrets process and set a rotation rule the owner can defend.
  5. Check that the audit trail attributes each change to the service identity, not to a person who merely scheduled the job.

Controlling the routes data leaves by

Access control inside the platform is only part of the problem. The routes that carry SAM data out are where sensitive pricing and installation data often escapes. Scheduled report emails sent to a distribution list that has grown over time are a classic case. So are exports to spreadsheets that get saved to shared drives, and integration payloads that include more fields than the receiving system needs.

Review each outbound route against the classification table. Remove fields the recipient does not use, restrict distribution to named groups, and log any export of contract pricing as a deliberate event. Where a route cannot be controlled, the data it carries should be reduced to the level the route can protect.

Evidence an auditor will ask to see

An auditor testing SAM access will ask for the mapping of data categories to roles, the list of service accounts with their owners, and the records of who changed access and when. They will also ask how a removed employee’s access was withdrawn from the SAM roles, and whether any outbound report has a current owner. A design that answers those questions from its own records holds up far better than one reassembled from memory during the audit itself.

Common questions about SAM access design

Can the licensing team be given read access to everything in SAM?

Not without a reason. The licensing team needs the data that supports entitlement decisions. Pricing, legal text and personal data should be granted only where the decision requires them, with the purpose recorded against the grant. The event-based role assignments show which decisions those grants support.

Should discovery credentials be shared across device groups?

Prefer separate credentials by device group or environment, so that a compromised credential exposes one group rather than all of them. The cost is more credentials to manage, which is worth it where the estate has distinct trust zones.

How do we handle a report that has been emailed to a group nobody recognizes?

Treat it as a data handling event. Confirm who receives the report, stop the distribution if it is no longer justified, record the event, and review the other scheduled reports for the same problem.

Is a separate SAM administrator account required for each person?

Each person who administers SAM should have their own named account, so that every configuration change can be attributed. Shared administrator logins can make the audit trail unusable for the changes that matter most.

Questions about SAM access design

Service accounts and outbound reports that have grown without a single owner are easier to bring back under control with a structured review. The access recertification article covers the review cycle that keeps access decisions current, and the access controls review guide covers reviewing access by the work each role performs.

Frequently asked questions

Should we let procurement see what software is deployed or hide software inventory?

Let procurement see software that relates to vendor agreements they manage. Hide software deployment details that procurement does not need. Balance transparency with privacy.

Can we delegate SAM administration to procurement or should IT retain it?

Procurement should manage vendor agreements and licenses. IT should manage software inventory and compliance checking. Some responsibilities split naturally; others benefit from shared ownership. Define clearly who does what.

What should we do if someone accesses SAM data they should not see?

Investigate whether access is a mistake (they were granted wrong role) or intentional breach. Revoke inappropriate access, retrain user on SAM policies, and log the incident. If pattern emerges, it may indicate security problem.

Talk to Oblytech

Planning, running or fixing a ServiceNow programme? Tell us where you are and we will suggest a sensible next step.

Contact us