ServiceNow says customers may perform application penetration testing against their sub-production instances under its Customer Penetration Testing Policy (ServiceNow, Security Best Practices Guide, September 2026). The public guide is labeled an Australia release and does not reproduce the policy. A US or Canadian buyer should treat it as a published summary, obtain the current account-applicable policy through its own ServiceNow Support access, and apply that policy before agreeing on a test date.
Quick answer. Scope a ServiceNow customer-instance penetration test around the customer's sub-production instance, configured access controls and business workflows. Prove whether ordinary users and integration identities can read or change records beyond their approved table, column and process permissions. Before booking, confirm the current Customer Penetration Testing Policy, the instance's update and hardening state, and the safe test methods and boundaries with your ServiceNow account team and testing provider (ServiceNow, Security Best Practices Guide).
The decision usually comes after a ServiceNow expansion: a new HR workflow, an ITSM integration, a custom app, a public-facing portal or a new machine identity. These changes create risks that a general platform report may not answer. The buyer needs an evidence-backed statement of work that names the customer-controlled paths, not just a line item for a web scan.
Use the provider report and customer test for different questions
ServiceNow's guide separates responsibilities. It says the customer determines access rights to its instance and data, while ServiceNow secures the platform infrastructure. It also says ServiceNow performs its own nightly web-application testing and commissions independent testing before major releases, with results available through the CORE Compliance Portal under NDA (ServiceNow, Security Best Practices Guide, pp. 6 and 42). Those documents help a buyer review the provider's platform assurance. They do not show whether the buyer's custom change-approval flow lets a requester approve its own ticket.
Start procurement by writing the question that the test must answer. Examples include: Can an HR case user read a field intended only for HR? Can a service-desk analyst change a task outside the analyst's support group? Can an integration account read an entire table when it only needs a named record subset? Can a portal user see another organization's request? Each can be proved with controlled identities and synthetic records in a sub-production instance configured to represent the relevant business path.
If the concern is underlying ServiceNow infrastructure, provider-hosted databases or another customer's instance, the buyer should seek the provider's assurance evidence rather than extend a customer-instance test into shared infrastructure. Our right-to-test clause guide describes the general SaaS permission issue. This article resolves the ServiceNow-specific purchase: what a customer can bring to a tester once its policy and instance boundary are settled.
Confirm policy and instance readiness before the technical plan
The public 2026 Australia-release guide's wording is narrow: customer application penetration testing against sub-production instances, in accordance with a separate Customer Penetration Testing Policy. It advises customers to decide which instances require tests and to define scope and duration with security and instance administrators. For annual application tests, the guide says the customer is required to install updates, harden the instance and meet the policy prerequisites before scheduling (ServiceNow, Security Best Practices Guide, p. 42). That wording should not be recast as a blanket annual testing mandate for every customer.
The full policy is account-gated, so a public article cannot assert its exact traffic limits, notification steps or permitted techniques. Ask the ServiceNow owner to supply the current policy to procurement and the testing firm through an authorized route. The SOW should record the version reviewed, required approvals or scheduling steps, permitted instance identifiers and any method limits. If a clause is unclear, resolve it with ServiceNow before testing. The contract is an input to the technical plan, not a footnote added after the scan.
Readiness also has a fidelity question. Sub-production may differ from production in roles, ACLs, data, installed applications, integration connections and patches. The test can be safe but irrelevant if it uses a stripped-down clone that omits the high-value workflow. The buyer should specify which controls must match production, which synthetic data replaces production records, and which differences are intentional. The report should include a short equivalence statement: what matched, what did not and how that limits the conclusion.
A minimum readiness pack contains the sub-production instance URL and release, application and update inventory, current hardening status, list of relevant customer-owned customizations, identities for the required roles, synthetic record fixtures, integration endpoints and owners, and an incident or stop contact. The access to policy and provider report can be controlled internally; the published article need not reproduce it. What matters is that the vendor sees the governing terms before sending traffic.
Design the test around business records and decisions
A ServiceNow test becomes useful when its findings can be tied to a decision a user is allowed to make. “Test ITSM” is too broad. “A requester cannot approve its own high-impact change, and a partner can see only its own tickets” is testable. The buyer should provide a matrix of actors, records and permitted transitions. The tester should challenge those assumptions from each exposed interface without disrupting live operations.
Workflow | Synthetic actors and records | Approved behavior | Test evidence |
|---|---|---|---|
Incident handling | Requester, service agent, assignment-group lead; synthetic incidents in two groups | Each actor reads and changes only its authorized records and fields | Before/after state, actor role, record owner and request trace |
Change approval | Requester, approver, implementation owner; synthetic change with controlled states | Approval and implementation actions stay separated by the customer's policy | State-transition trace and named rule that allowed or denied it |
HR or sensitive case | Employee, HR agent, restricted manager; synthetic sensitive fields | Only authorized roles can see protected case data and attachments | Field-level response comparison and access decision |
Customer or partner portal | Two synthetic external organizations and distinct cases | External users see their organization's intended records only | Cross-organization comparison using authorized test accounts |
Custom app | Named role set, table and user-specific business rule | Read, create, update and delete align with the app's published entitlement design | Table and column ACL result plus business-rule observation |
This is a sample matrix, not a statement of how any customer's instance is configured. It forces the buyer to say what “authorized” means before testing begins. Without that baseline, a report may call expected business behavior a vulnerability or overlook a real privilege crossing because a role sounds powerful.
ServiceNow's secure-data documentation says access controls can be configured at both table and column level and explains that before-query Business Rules can affect record visibility but do not replace ACLs (ServiceNow Docs, Secure data). Therefore, do not accept a test that checks only whether a table appears in the navigation menu. An endpoint, portal component or scripted query can reveal a different effective outcome. The test should compare UI, API and relevant custom logic for the same actor and synthetic record.
Figure 1: Roles, ACLs, workflows and API paths all affect the effective customer-record decision. Source: ServiceNow Docs, Secure data.
ACLs and roles: use non-admin accounts to prove access
ServiceNow's guide states that the System Administrator role can override ACL rules and pass role checks (ServiceNow, Security Best Practices Guide, p. 5). This makes an admin-only penetration test especially weak for access-control questions. Give testers accounts that represent the business population whose restrictions matter: a basic requester, service agent, elevated workflow approver, partner user and service identity as appropriate.
For each sensitive table, record the operations and columns the actor should reach. A useful negative test pairs a permitted action with a similar forbidden one. For example, a service agent may be able to update an incident assigned to its group but not an incident assigned elsewhere. The tester should use synthetic records so the observed difference is attributable to authorization, not data sensitivity or accidental production side effects.
Pay attention to inherited roles, group changes and elevated privileges. An account can gain effective access through more than one path. The report should tell the administrator which role, group, ACL, script or business rule produced the observed result. A finding that merely says “user can read table” is insufficient if the business owner cannot see which entitlement to change.
ServiceNow's documentation describes both ACLs and before-query Business Rules. It says before-query rules can hide records from a result without replacing ACLs, and that access-control evaluation order matters (ServiceNow Docs, Secure data). The tester can use configuration review to identify these components, then prove the actual access result with a request made as a restricted user. A configuration screenshot and an observed response are complementary; neither alone is the whole test.
Column checks deserve their own cases. An HR case might be visible to a service role while a particular field is not. A portal might display a sanitized summary but return a more complete JSON object in the backing call. The test should state the expected visibility of each high-value field and compare the response shape across the UI and API. This is a better acceptance criterion than “check for data exposure,” which leaves the tester to guess what the buyer considers sensitive.
Workflow and custom app logic: trace the decision, not only the page
Many ServiceNow implementations encode approvals and state transitions in customer-configured workflows, scripts and custom apps. A security test should follow the permitted business transition and a nearby forbidden transition. For an approval flow, that could be a requester attempting to self-approve a synthetic change. For HR, it could be a manager attempting to see a case outside its defined relationship. The tester should stop at a safe proof that a rule was bypassed rather than carry out an operational change.
The scope should list the exact workflows with security impact. Prioritize those that provision access, release software, modify asset records, approve spending, send files to an external system or disclose employee and customer information. These are editorial risk criteria, not claims about ServiceNow defaults. The process owner should define the state machine and segregation expectations in writing, because a tester cannot infer them from a screen label.
Custom application testing may need both authenticated dynamic testing and source-assisted review. A visible portal path can be tested as a user. A scripted action's reason for allowing that user may be clearer in code or configuration. If source access is unavailable, the report should say which paths were observed and which implementation details remain uncertain. If the customer supplies code and configuration export, the testers can connect the response to a specific ACL, script or workflow condition.
Avoid promising a platform-wide code audit under a narrow instance test. The SOW should identify named custom apps, tables, endpoints and workflows. If there is a large backlog of customizations, select the ones tied to privileged actions or sensitive data and state the sampling logic. A buyer can then decide whether the first test answers the pressing security question or whether a wider program is justified.
API, file and MID Server boundaries
ServiceNow's guide assigns customers responsibility for their instance's file-transfer and web-service settings. It specifically recommends inbound REST API rate limiting and review of public REST endpoints, including whether unauthenticated access is appropriate (ServiceNow, Security Best Practices Guide, pp. 36–37). If an API is in scope, the SOW should name its route, authentication model, integration identity, expected tables and rate controls. The test should validate authorization as well as authentication: a valid integration credential can still have too much record or column access.
A safe API test can use synthetic records and a bounded request budget. The purpose is to compare effective rights across a named machine identity and an ordinary user, or across two integration identities, rather than generate traffic to see when the service fails. If a public endpoint is intended, the business owner should define exactly what data is public. Findings should show a sanitized request, response and policy mismatch. Bulk extraction is not needed to establish a read-access error.
The MID Server is a different boundary. ServiceNow describes it as a customer-operated component that communicates between the instance and external applications or data sources. The customer is responsible for its OS hardening, network access and credentials (ServiceNow, Security Best Practices Guide, p. 32). An instance application test does not automatically authorize testing an on-premises MID Server, its connected network devices or a third-party system. If the buyer wants that path assessed, add the host, owner, network segment, accounts and methods as a separately approved boundary.
This division also prevents findings from being routed to the wrong team. An overly broad ServiceNow integration role belongs to the instance owner. A weak MID Server OS configuration belongs to the infrastructure owner. A third-party API flaw may require a vendor process. The report should assign the control owner and stop short of claiming that one assessment covered every connected system.
Preserve monitoring evidence while testing
The test should produce both vulnerability evidence and evidence that the customer's monitoring sees relevant actions. ServiceNow's guide says customers can access end-user activity, failed logins, audit trails, record histories and administrative escalations, and it describes API Analytics for inbound REST and SOAP activity (ServiceNow, Security Best Practices Guide, pp. 39–41). The buyer can ask its defenders to correlate a small set of agreed synthetic tests to the instance records and its own SIEM.
This does not require a red-team exercise. A bounded validation can show whether a denied ACL action is logged, whether a privileged role change is visible and whether an integration call can be attributed to the right identity. If logging differs between sub-production and production, state that limit. A test cannot certify a production detection pipeline it never exercised.
Evidence handling is also a data-governance decision. Use synthetic tickets, cases, attachments and identities. If unavoidable production-like data enters sub-production, agree who sanitizes it before the tester sees it. Ask the vendor for a retention and deletion plan for screenshots, HTTP traces and exported configuration. A high-quality report makes the authorization failure reproducible without embedding sensitive personal data in every appendix.
A SOW and acceptance matrix the buyer can use
Write the contract so that a reviewer can trace every test objective to a customer-owned control and an expected deliverable. The provider's public guide, the account-gated policy and the customer's instance design each contribute a different part of the scope. The signed SOW should say which policy version the parties reviewed and which assumptions remain unresolved.
SOW element | Buyer provides | Vendor delivers | Acceptance test |
|---|---|---|---|
Policy and environment | Current Customer Penetration Testing Policy, sub-production instance, release, update and hardening status | Written rules of engagement matched to the policy | No active work before prerequisites and named instance are confirmed |
Fidelity | Production-to-sub-production comparison for apps, ACLs, roles and integrations | Coverage statement and explicit differences | Report does not imply production assurance for absent paths |
Business matrix | Sensitive tables, columns, workflows, actors and approved decisions | Positive and negative tests for each selected path | Each result ties actor, record, rule and observed behavior |
API and integration | Named endpoints, service identities, rate limits and external owners | Controlled authorization tests and sanitized traces | No test expands into another system without its own authorization |
Safe data | Synthetic records, attachments and cleanup owner | Reproducible findings with minimal data | Test data is tracked and removed or retained by agreement |
Monitoring | Sub-production logs and defender point of contact | Selected event correlations and visibility limits | Detection claims are limited to telemetry actually observed |
Report and retest | Finding owners and remediation process | Root cause, impact, fix guidance and repeat of failed case | A retest shows the same restricted identity now gets the expected result |
A buyer should also ask for an explicit stop condition if testing changes business records unexpectedly or affects availability. The technical lead should agree on the allowed request budget and any workflow actions that require a pause. These are choices for the customer and its testing provider under the current policy. The public guide does not publish a universal traffic number to copy into every SOW.
The report should separate three verdicts: control works for the sampled cases; control fails for a specific identity and path; and control was not tested. That last verdict is valuable. It prevents a broad title from concealing a narrow sample. Findings should state the data type, business consequence, actor, path, affected app or table, evidence and owner. A manager should be able to determine whether to change an ACL, workflow, role or integration credential without reconstructing the entire test.
Where Stingrai fits
Stingrai is a CREST-accredited penetration testing provider headquartered in Toronto. A human-led ServiceNow customer-instance assessment can be scoped around authenticated web and API paths, role and ACL boundaries, custom workflows and business-logic decisions. The team uses two named penetration testers on a human-led engagement, with review by its team lead and engagement partner. That model is useful where a false-positive scan result or an ambiguous approval rule needs a human comparison against the customer's documented policy.
The ServiceNow instance, policy conditions, custom applications and any separately authorized MID Server work should all be named in the quote. Stingrai's confirmed findings are made available during the engagement with remediation guidance, and retesting of remediated findings is included. The final report can support the customer's security and audit evidence, while the customer remains responsible for its implementation and vendor-policy decisions.
A scoped instance test is most valuable when the buyer can hand the testers the actor-record matrix and approve the negative cases. If that matrix is missing, the first productive step is a scoping workshop with the platform owner and the process owners. The result should be a test plan that measures the business rules that matter, not a list of screens.
Frequently Asked Questions
Can customers penetration test a ServiceNow instance?
ServiceNow's September 2026 Security Best Practices Guide says customers may perform application penetration testing against their sub-production instances in accordance with the Customer Penetration Testing Policy. The customer should retrieve the current account-gated policy and meet its prerequisites before scheduling.
Does ServiceNow require every customer to run an annual penetration test?
The public guide discusses preparation for annual application penetration tests, including updates, hardening and policy prerequisites. It does not establish a blanket annual testing mandate for every customer in the text cited here. Set frequency from the customer's risk and contractual obligations, using the current policy for each planned test.
Is a ServiceNow platform penetration-test report enough?
It can answer questions about ServiceNow's provider testing, but it cannot prove that a customer's configured ACLs, roles, workflows and integrations enforce the customer's own business rules. A customer-instance test uses controlled identities and synthetic records to examine those implementation decisions.
Why test with non-admin users?
ServiceNow says its System Administrator role can override ACL rules and pass role checks. A test performed only as admin therefore cannot prove whether ordinary employees, external users or integrations are correctly limited. Use identities that represent the actual restricted population.
What should a ServiceNow pentest SOW name?
Name the sub-production instance and release, policy prerequisites, update and hardening status, production-equivalence limits, apps and workflows, table and column rules, test identities, synthetic records, API and integration boundaries, evidence format, stop contact and retest criteria. Each selected control should have an expected result and a safe observation method.
Is a MID Server included in an instance application test?
No automatic inclusion follows from the instance scope. ServiceNow describes the MID Server as a customer-operated component connecting the instance with external systems. Testing its host, credentials or connected network needs a separately named and authorized boundary in the SOW.
Related reading
References
ServiceNow, Security Best Practices Guide, September 2026, Australia release.
Talk to Stingrai
Stingrai can help turn your customer-owned ServiceNow access and workflow rules into a human-led test with findings your platform team can use. Get a Quote or book a free discovery call.
