Direct navigation: 11/11 documented All > ... paths linked to this ServiceNow instance.

GRC — Professional Implementation from Scratch to Production

Release baseline: ServiceNow Australia (current GA · Sep 2026)
Audience: Professional Implementers · Platform Admins · Developers · Product Owners · Test Leads
Instance token: {BASE} = https://YOUR_INSTANCE.service-now.com
Related module encyclopedia: ../GRC.md
All implementation guides: INDEX.md

0. Outcome and guardrails

Governance, Risk and Compliance / IRM: Translate authority requirements into policies, controls, tests, risks, issues, audits, evidence, and remediation with defensible traceability.

• Confirm product entitlement before plugin activation.
• Build and test in sub-production/PDI; never activate major plugins first in production.
• Prefer out-of-box process/configuration before custom scripts.
• Use Flow Designer for new automation; maintain legacy Workflow only when required.
• Protect data with roles, ACLs, groups, criteria, and persona-based tests.
• Australia is the deployment baseline; Brazil preview/EA is not the production baseline unless your organization explicitly validates it.

1. End-to-end operating model

Discover → Design → Configure → Integrate → Secure → Test → Deploy → Operate → Improve

Module lifecycle: Authority Document → Citation → Policy → Control Objective / Control → Indicator/Test → Finding/Issue → Remediation; Entity → Risk → Assessment → Response/Acceptance

2. Discovery workshops and scope

Run these workshops before configuration:

3. Licensing, plugins, and release readiness

Expected products/plugins: Integrated Risk Management; Policy and Compliance; Risk Management; Audit Management; Vendor Risk Management; Business Continuity (licensed options)

1. Open Plugins.
2. Confirm entitlement with ServiceNow account/product owner.
3. Activate in a non-production instance.
4. Review activation logs and newly created roles/modules.
5. Capture configuration in a named Update Set where supported.
6. Confirm Australia release/build at System Stats.

4. Roles, groups, and security model

Typical roles: sn_compliance_admin, sn_compliance_user, sn_risk_admin, sn_risk_user, sn_audit_admin, sn_grc_internal

Professional rules:

• Roles → Groups → Users; avoid direct role grants.
• Separate admin/configurer, manager, fulfiller/agent, requester, auditor, and integration personas.
• Test table, row, and field access with impersonation.
• Never treat UI visibility as security; enforce ACL/criteria.
• Record privileged access and quarterly access review.

5. Foundation configuration sequence

1. Create reference data and ownership groups.
2. Configure states/models/templates before automation.
3. Configure assignment/routing and schedules.
4. Configure SLAs/entitlements where applicable.
5. Configure notifications and knowledge.
6. Configure workspace/portal/mobile experience.
7. Configure integrations and system properties.
8. Build reports and dashboards.
9. Build ATF and UAT packs.
10. Complete deployment/rollback runbook.

6. All component pages and direct URLs

Enter your instance once in the HTML header; every {BASE} link then opens the correct page in that instance.

7. Module configuration tutorial

1. Open each component in the order shown in §6.
2. Create minimum viable reference data and one happy-path record.
3. Configure state transitions, assignment, approvals, notifications, and SLAs.
4. Validate agent and requester experiences using different personas.
5. Add exception paths: rejection, reassignment, cancellation, timeout, integration failure.
6. Keep customization decisions in an OOTB-vs-config-vs-custom register.

7.1 Complete settings and configuration control matrix

Use this as the minimum configuration workbook. Add product-specific rows discovered during workshops; do not leave a changed setting without an owner and test.

Configuration rule for GRC: record OOTB default, approved value, owner, rationale, environment, transport method, and test case for every changed setting.

7.2 Component-by-component hands-on labs

Complete every lab below in a non-production instance. These labs cover every module-specific page listed in §6.

Component Lab 1 — Authority Documents

Purpose: External obligations
Navigator: All > Policy and Compliance > Authority Documents — Open direct
Direct: Open Authority Documents

1. Confirm plugin, role, group, and prerequisite reference data.
2. Open the direct page and review OOTB fields, states, related lists, and existing records.
3. Create a pilot record named/prefixed LAB-01 where the component supports records.
4. Configure owner, entity/profile, lifecycle, assessment/test frequency, evidence, and approvals.
5. Test overdue, failed, exception, issue, remediation, and closure evidence paths.
6. Impersonate requester/agent/manager/admin as applicable; record expected and actual results.
7. Capture evidence: URL, sys_id/number, screenshot, configuration decision, owner, and rollback step.

Component Lab 2 — Policies

Purpose: Internal requirements
Navigator: All > Policy and Compliance > Policies — Open direct
Direct: Open Policies

1. Confirm plugin, role, group, and prerequisite reference data.
2. Open the direct page and review OOTB fields, states, related lists, and existing records.
3. Create a pilot record named/prefixed LAB-02 where the component supports records.
4. Configure ownership, required fields, references, lifecycle, security, and automation for: Internal requirements.
5. Test create/read/update/close and a negative-access case with the correct personas.
6. Impersonate requester/agent/manager/admin as applicable; record expected and actual results.
7. Capture evidence: URL, sys_id/number, screenshot, configuration decision, owner, and rollback step.

Component Lab 3 — Controls

Purpose: Control implementation
Navigator: All > Policy and Compliance > Controls — Open direct
Direct: Open Controls

1. Confirm plugin, role, group, and prerequisite reference data.
2. Open the direct page and review OOTB fields, states, related lists, and existing records.
3. Create a pilot record named/prefixed LAB-03 where the component supports records.
4. Configure owner, entity/profile, lifecycle, assessment/test frequency, evidence, and approvals.
5. Test overdue, failed, exception, issue, remediation, and closure evidence paths.
6. Impersonate requester/agent/manager/admin as applicable; record expected and actual results.
7. Capture evidence: URL, sys_id/number, screenshot, configuration decision, owner, and rollback step.

Component Lab 4 — Indicators

Purpose: Continuous/manual tests
Navigator: All > Policy and Compliance > Indicators — Open direct
Direct: Open Indicators

1. Confirm plugin, role, group, and prerequisite reference data.
2. Open the direct page and review OOTB fields, states, related lists, and existing records.
3. Create a pilot record named/prefixed LAB-04 where the component supports records.
4. Define source, filter, aggregation, breakdown, sharing roles, target, and owner.
5. Reconcile displayed value against the source list and security model.
6. Impersonate requester/agent/manager/admin as applicable; record expected and actual results.
7. Capture evidence: URL, sys_id/number, screenshot, configuration decision, owner, and rollback step.

Component Lab 5 — Risks

Purpose: Risk register
Navigator: All > Risk > Risks — Open direct
Direct: Open Risks

1. Confirm plugin, role, group, and prerequisite reference data.
2. Open the direct page and review OOTB fields, states, related lists, and existing records.
3. Create a pilot record named/prefixed LAB-05 where the component supports records.
4. Configure owner, entity/profile, lifecycle, assessment/test frequency, evidence, and approvals.
5. Test overdue, failed, exception, issue, remediation, and closure evidence paths.
6. Impersonate requester/agent/manager/admin as applicable; record expected and actual results.
7. Capture evidence: URL, sys_id/number, screenshot, configuration decision, owner, and rollback step.

Component Lab 6 — Risk Assessments

Purpose: Inherent/residual scoring
Navigator: All > Risk > Assessments — Open direct
Direct: Open Risk Assessments

1. Confirm plugin, role, group, and prerequisite reference data.
2. Open the direct page and review OOTB fields, states, related lists, and existing records.
3. Create a pilot record named/prefixed LAB-06 where the component supports records.
4. Configure owner, entity/profile, lifecycle, assessment/test frequency, evidence, and approvals.
5. Test overdue, failed, exception, issue, remediation, and closure evidence paths.
6. Impersonate requester/agent/manager/admin as applicable; record expected and actual results.
7. Capture evidence: URL, sys_id/number, screenshot, configuration decision, owner, and rollback step.

Component Lab 7 — Issues

Purpose: Findings and remediation
Navigator: All > GRC > Issues — Open direct
Direct: Open Issues

1. Confirm plugin, role, group, and prerequisite reference data.
2. Open the direct page and review OOTB fields, states, related lists, and existing records.
3. Create a pilot record named/prefixed LAB-07 where the component supports records.
4. Configure ownership, required fields, references, lifecycle, security, and automation for: Findings and remediation.
5. Test create/read/update/close and a negative-access case with the correct personas.
6. Impersonate requester/agent/manager/admin as applicable; record expected and actual results.
7. Capture evidence: URL, sys_id/number, screenshot, configuration decision, owner, and rollback step.

Component Lab 8 — Audit Engagements

Purpose: Audit execution
Navigator: All > Audit > Engagements — Open direct
Direct: Open Audit Engagements

1. Confirm plugin, role, group, and prerequisite reference data.
2. Open the direct page and review OOTB fields, states, related lists, and existing records.
3. Create a pilot record named/prefixed LAB-08 where the component supports records.
4. Configure owner, entity/profile, lifecycle, assessment/test frequency, evidence, and approvals.
5. Test overdue, failed, exception, issue, remediation, and closure evidence paths.
6. Impersonate requester/agent/manager/admin as applicable; record expected and actual results.
7. Capture evidence: URL, sys_id/number, screenshot, configuration decision, owner, and rollback step.

Component Lab 9 — Evidence

Purpose: Defensible proof
Navigator: All > Policy and Compliance > Evidence — Open direct
Direct: Open Evidence

1. Confirm plugin, role, group, and prerequisite reference data.
2. Open the direct page and review OOTB fields, states, related lists, and existing records.
3. Create a pilot record named/prefixed LAB-09 where the component supports records.
4. Configure owner, entity/profile, lifecycle, assessment/test frequency, evidence, and approvals.
5. Test overdue, failed, exception, issue, remediation, and closure evidence paths.
6. Impersonate requester/agent/manager/admin as applicable; record expected and actual results.
7. Capture evidence: URL, sys_id/number, screenshot, configuration decision, owner, and rollback step.

Component Lab 10 — Vendor Assessments

Purpose: Third-party assurance
Navigator: All > Vendor Risk Management > Assessments — Open direct
Direct: Open Vendor Assessments

1. Confirm plugin, role, group, and prerequisite reference data.
2. Open the direct page and review OOTB fields, states, related lists, and existing records.
3. Create a pilot record named/prefixed LAB-10 where the component supports records.
4. Configure ownership, required fields, references, lifecycle, security, and automation for: Third-party assurance.
5. Test create/read/update/close and a negative-access case with the correct personas.
6. Impersonate requester/agent/manager/admin as applicable; record expected and actual results.
7. Capture evidence: URL, sys_id/number, screenshot, configuration decision, owner, and rollback step.

Component Lab 11 — BCM Plans

Purpose: Resilience planning
Navigator: All > Business Continuity > Continuity Plans — Open direct
Direct: Open BCM Plans

1. Confirm plugin, role, group, and prerequisite reference data.
2. Open the direct page and review OOTB fields, states, related lists, and existing records.
3. Create a pilot record named/prefixed LAB-11 where the component supports records.
4. Configure ownership, required fields, references, lifecycle, security, and automation for: Resilience planning.
5. Test create/read/update/close and a negative-access case with the correct personas.
6. Impersonate requester/agent/manager/admin as applicable; record expected and actual results.
7. Capture evidence: URL, sys_id/number, screenshot, configuration decision, owner, and rollback step.

8. Integration architecture

CMDB/entity sources; vulnerability/SecOps; vendor data; HR attestations; document repositories; external GRC feeds; ITSM changes as remediation evidence.

For every interface define:

Direct: Scripted REST · REST Messages · Connections

9. Reporting and Performance Analytics

KPIs: Control compliance, overdue tests, issue aging, residual risk, accepted risk expiry, audit finding closure, vendor risk tier, evidence freshness.

1. Build operational reports first.
2. Create role-based dashboard.
3. Add PA indicators/targets only when licensed and historical trend is required.
4. Validate report sharing and underlying ACLs.

Direct: Create Report · Reports · Dashboards · PA Indicators

10. Testing strategy

Direct: ATF Tests · ATF Suites

11. Deployment from development to production

1. Freeze scope and configuration.
2. Peer-review Update Set/App Repo contents.
3. Promote to test; Preview before Commit.
4. Resolve collisions deliberately.
5. Run ATF, security, integration, and UAT evidence.
6. Prepare data migration/cutover and communications.
7. Approve change record and rollback plan.
8. Deploy in agreed window.
9. Execute smoke tests and monitor.
10. Handover support ownership/runbooks.

Direct: Local Update Sets · Retrieved Update Sets · Upgrade History

12. Hands-on implementation lab

This full lab program covers platform readiness, security, all settings, module configuration, exception handling, experience, integration, data, reporting, testing, deployment, and operations.

Lab 0 — Instance and release readiness

1. Confirm Australia build at System Stats.
2. Verify entitlement/dependencies at Plugins.
3. Create Update Set LAB-MODULE-FOUNDATION.
4. Record baseline screenshots/properties and rollback owner.

Lab 1 — Personas, groups, roles, and security

1. Create requester, fulfiller/agent, manager, admin, auditor, and integration test users.
2. Create functional groups and grant roles to groups.
3. Build the role/access matrix and validate it through impersonation.
4. Test one unauthorized read and one unauthorized update.

Direct: Users · Groups · Roles · ACLs

Lab 2 — Module core happy path

Execute these module-specific steps:

• Create one authority document/citation and map it to a policy.
• Create control objective and control; assign owner and entity.
• Create an indicator/test and collect evidence.
• Register a risk; complete inherent and residual assessment.
• Fail a control test to create Issue and Remediation Task.
• Create a small audit engagement and executive risk/compliance dashboard.

Lab 3 — Settings and exception paths

1. Complete every row in the settings workbook (§7).
2. Test missing mandatory data, invalid transition, reassignment, cancellation, rejection, timeout, and reopen.
3. Verify fallback assignment and ownership when no rule matches.
4. Confirm system properties differ correctly by environment.

Lab 4 — Automation, SLA, and notifications

1. Create/validate Flow trigger and all branches.
2. Configure approval timeout and escalation.
3. Validate SLA start/pause/resume/stop and breach.
4. Validate event registry, notification conditions, recipients, and email log.

Direct: Flow Designer · SLA · Notifications · Email Log

Lab 5 — Workspace, portal, and mobile

1. Configure persona lists/forms/actions.
2. Publish requester content/service where applicable.
3. Complete one end-to-end transaction as requester and fulfiller.
4. Validate accessibility, empty state, error state, and mobile behavior when licensed.

Lab 6 — Integration and migration

1. Define contract/schema, correlation key, authentication, and ownership.
2. Configure Connection Alias/Credential and environment property.
3. Test success, invalid payload, unauthorized, duplicate, timeout, retry, and replay.
4. Load a small migration file; validate coalesce, rejects, and reconciliation.

Direct: REST Explorer · Scripted REST · REST Messages · Transform Maps

Lab 7 — Reports, dashboard, and PA

1. Build volume, backlog, aging, SLA/target, exception, and trend reports.
2. Build manager/agent/executive dashboard variants.
3. Validate sharing roles and source ACL behavior.
4. If licensed, configure PA indicator source, collector, breakdown, target, and widget.

Lab 8 — ATF, UAT, and regression

1. Create smoke suite for create, route, progress, resolve/close.
2. Add security negative tests and core exception branches.
3. Execute UAT by persona and link defects to scenarios.
4. Export pass evidence and define upgrade regression suite.

Lab 9 — Deployment and hypercare

1. Preview Update Set in test and resolve all collisions.
2. Run ATF/UAT/integration/security checks.
3. Execute approved change and production smoke tests.
4. Monitor 24–72 hours; document defects, owners, SLA, and rollback decision.
5. Handover admin guide, fulfiller guide, dashboard, and support runbook.

Lab evidence: screenshots, record numbers, test-user results, Update Set, ATF result, dashboard, and rollback note.

13. Production operations

• Daily: queue/backlog, failures, SLAs, integration errors.
• Weekly: aging, throughput, exceptions, knowledge gaps.
• Monthly: KPIs, adoption, automation candidates, access exceptions.
• Quarterly: role review, retention, controls, upgrade readiness.

14. Definition of Done

• [ ] Entitlement/plugins and Australia compatibility confirmed
• [ ] Every §6 component lab completed with evidence
• [ ] Every §7 settings row has approved value, owner, transport, and test
• [ ] Signed scope, process, data, security, integration, KPI decisions
• [ ] Roles granted through groups and negative security tests passed
• [ ] Reference data, process, routing, SLA/entitlement configured
• [ ] Workspace/portal/mobile experience validated as applicable
• [ ] Integration controls and failure handling tested
• [ ] Reports/dashboard accepted by product owner
• [ ] ATF smoke + UAT + performance checks passed
• [ ] Deployment, rollback, support, and monitoring runbooks approved
• [ ] Knowledge transfer and operational ownership completed

15. 30/60/90-day maturity roadmap