ServiceNow Update Sets and Release Management: Security and Access Design

Understanding Update Set Access Control

Update Sets are ServiceNow’s mechanism for moving configuration changes between environments (development, testing, production). An Update Set captures all configuration changes made in one environment, which can then be moved to another environment. Controlling who can create, edit, and deploy Update Sets is critical for system stability and security.

Without proper access control, developers could bypass change management and deploy untested changes directly to production. Security configuration could be weakened. Or, configuration could be accidentally overwritten. Access control ensures only authorized people can modify configuration, and changes follow a proper release process.

Role-Based Access Model for Update Sets

Define four core roles: Developer (creates Update Sets in development environment, cannot deploy to production), Release Manager (reviews Update Sets, approves for testing and production), Tester (promotes Update Sets to testing, runs tests), and Deployer (deploys approved Update Sets to production).

Developers can create and edit Update Sets in development. They cannot promote to testing or production; Release Manager must approve. Release Manager reviews change summary, impact analysis, and test results before approving production deployment.

Testers can promote Update Sets to testing environment and run tests. They provide test results to Release Manager. Testers cannot deploy to production.

Deployer role deploys approved Update Sets to production only after Release Manager approval. Deployer does not decide if changes are good; Release Manager does.

Segregation of Duties

A developer should not be able to deploy their own changes to production. This prevents mistakes or malicious changes. Require a different role for approval and deployment.

Change request process should link to Update Sets: when a change request is approved, the associated Update Set can be promoted. If change request is rejected, the Update Set cannot be promoted. This enforces change management discipline.

Rollback responsibility: if a deployed change causes problems, who has authority to roll back? Usually the Deployer role or Release Manager. Document rollback authority and procedures.

Environment-Specific Access

Developers work primarily in development environment. They should have limited access to testing and production (read-only for viewing configuration, not modification). This prevents accidental or intentional changes to higher environments outside the release process.

Testers and Release Managers need access to testing and production for testing and release management but should not make direct configuration changes (except in emergency circumstances, with audit trail).

Production environment should have minimal direct access. All changes flow through Update Sets and change management process. Emergency changes (security fixes, critical outages) can bypass normal process but must be documented and audited.

Audit Evidence and Change Tracking

ServiceNow automatically tracks Update Set changes: who created the Update Set, what changes are included, who promoted it, when was it deployed. This audit trail is critical for compliance and troubleshooting.

For each Update Set, document: business reason for the change (linked change request), who approved it, test results, and deployment results. If a deployed change causes problems, the audit trail shows exactly what changed, who approved it, and when.

When Update Sets are deployed, capture before/after state: what was the configuration before the Update Set was deployed? What is it after? This allows precise rollback if needed.

Emergency and Exception Procedures

For emergency changes (critical security fix, production outage requiring immediate action), allow direct configuration changes in production with post-deployment approval. Capture evidence of the emergency (incident record) and who made the change. Document the business justification.

Direct changes should be rare. If they become frequent, the system is not working properly. Investigate: are normal change processes too slow? Is there resistance to using Update Sets? Address root causes.

Access Review and Recertification

Quarterly, review who has Update Set and deployer access. Verify they still need it (have they changed roles?), they still work at the organization (are they still employees?), and they have not accumulated permissions they do not need. Revoke access for people who have left or changed roles.

Access by environment, not by job title alone

Access reviews often start from job titles, and titles tell you little about what a person can do on a given day. The control that matters is the combination of the person, the environment and the action. A developer may have full edit rights in a sandbox, read-only rights in test and no rights at all in production. A release manager may approve promotions without being able to edit the records being promoted. Draw the matrix before assigning roles, because it exposes combinations that look harmless in a list but allow one person to make and release a change without review.

Protecting the set records themselves

Sets are records, and records can be edited. Anyone who can change the update set or update content records can alter what a reviewer approved without leaving an obvious trace. Restrict edit rights on those records to the platform’s administrative group, and have the audit trail record every change to them. Watch for sets whose contents change after completion, since a completed set that changes is a strong signal that the approved version is no longer the one being released. Protecting the records is cheaper than explaining, after an incident, why the approved content and the promoted content differ.

Monitoring activity that bypasses the release path

Much unauthorized change reaches production by a route the release process did not expect, such as a direct edit to a live rule or an administrator importing a file from a personal download. Build a simple report that lists configuration changes made in production that do not link to an approved set or change record. Review it at a regular cadence. The report does not need to be sophisticated; it needs to be read by someone who has the authority to ask why an unlinked change happened.

Break-glass access that is used rarely and recorded every time

Some teams keep a standing administrative account for emergencies. That account is convenient on the night of an outage and dangerous every other night, because its use is hard to attribute and its rights are seldom reviewed. A safer design gives emergency rights to named people, activates them only against an open incident reference, expires them automatically and reports every use to the governance owner the next working day. The access recertification guide explains how to keep such grants from quietly becoming permanent.

Access review procedure

1. Export the list of people who can create, commit, import or back out sets in each environment.
2. Compare each name against the current staff list and the current role assignments in the release chart.
3. Remove rights from anyone who has changed roles or left, and record the removal as a restricted change.
4. Check that no single person holds both the author role and the deployer role for the same set.
5. Confirm that emergency access is held by named people, can be used only with an incident reference, and is reported after use.

Run the review on a fixed cadence that the release calendar cannot postpone. Reviews that slip during busy periods often find more stale grants, because the people who changed roles during the busy period are the ones nobody remembered to remove.

Frequently asked questions about access to update sets

Should testers be able to fix a defect they find?

Testers should log the defect and return it to the builder, not change the configuration directly in test. A tester who edits the configuration has made a change that is not in any set, and the next import may silently overwrite it.

Is it acceptable to give a vendor partner production access during a project?

Only through the same roles, the same approval route and time-limited rights that apply to internal staff. Access granted for a project tends to outlive the project unless its end date is recorded and checked.

Which records prove an access review took place?

The list reviewed, the decision made for each name, the reviewer’s name and the date. Keep the removals as their own records, so an auditor can see that access was withdrawn rather than never granted.

Next step for your update set access model

The access controls review guide covers the wider platform permissions that sit around the release path.