Dot-Walk Scoping Security Enhancement - Re-establishing CrossScopeAccess logging after clones

[Jeff Boltz1]

Hello Community,

We're working through ServiceNow's Dot-Walk Scoping Security Enhancement assessment and are looking for practical experience with establishing and maintaining the Log and Allow / CrossScopeAccess logging prerequisites.

We previously had CrossScopeAccess logging working successfully in a sub-production environment and collected useful assessment data. Following an environment refresh/clone, however, we are no longer seeing CrossScopeAccess logging activity.

Our challenge is making this configuration repeatable.

In our environment, normal administrators have also been unable to create the required sys_logger_configuration records. Previous troubleshooting required elevated syslog_admin access to establish the logger configuration.

For anyone who has implemented the Dot-Walk Scoping Security Enhancement assessment process:

1. How are you establishing the prerequisite Log and Allow / CrossScopeAccess logging configuration in each environment?

2. Are normal platform administrators able to create the required sys_logger_configuration records, or did you require additional privileges or ServiceNow assistance?

3. How are you handling this configuration following sub-production clones or refreshes?

4. What do you validate after setup to confirm CrossScopeAccess telemetry is actually being generated correctly?

5. Have you created a repeatable deployment or post-clone procedure for this configuration?

I'm specifically asking about the Dot-Walk Scoping Security Enhancement logging prerequisite rather than general Runtime Access Tracking, Cross Scope Privileges (CSP), or Restricted Caller Access (RCA) behavior.

Our goal is to establish a supported, repeatable method for generating assessment data before making any enforcement-readiness decision.

Interested in hearing from anyone who has worked through this operationally.

Thanks,

Jeff