← Home
🔥0 DAY
⚡0 XP
Interview Prep · IRM / GRC

IRM ARCHITECT
INTERVIEWS.

Senior ServiceNow IRM/GRC interviews probe risk math, control testing strategy, and how the profile layer connects everything. Below: a fast answer summary, four simulator-backed lessons, and ten architect-level scenario questions with a recommended answer, a defensible alternate approach, and the pitfall interviewers listen for.

Pair with the ACL scripting guide for platform security depth, or drill the same topics in the IRM practice track.

Answer summary — the ten things you must be able to say

Short, quotable answers to the questions that open almost every IRM architect screen. Read these first, then work the scenarios.

What does a ServiceNow IRM architect actually own?
The GRC data model (profile types, profiles, entity hierarchy), the risk scoring framework, control and indicator design, and the integration contracts between IRM, CMDB, ITSM, and Vendor Risk. You own how risk is measured and evidenced — not the day-to-day assessments.
Which tables should you be able to name from memory?
sn_risk_risk, sn_risk_definition, sn_risk_criteria, sn_grc_profile, sn_grc_profile_type, sn_grc_policy, sn_compliance_control, sn_compliance_policy_statement, sn_grc_indicator, sn_grc_indicator_result, sn_grc_issue, sn_grc_remediation_task, sn_vdr_risk_asmt_assessment.
How is residual risk calculated?
Residual = inherent × (1 − aggregate control effectiveness), where inherent = likelihood × impact scored before controls. Aggregate effectiveness is averaged across mapped controls, never compounded.
Profile vs. entity vs. entity type — what's the difference?
An entity type (sn_grc_profile_type) defines what class of thing is assessed; a profile (sn_grc_profile) is one assessable instance pointing at a source record; entity filters populate profiles automatically from a table condition, so the population stays live.
When do you use an indicator instead of an attestation?
Use an indicator whenever the evidence already exists in a table and can be queried on a schedule — access reviews, change approvals, patch currency. Reserve attestations for judgement-based controls with no queryable source.
How does IRM connect to CMDB?
Through profiles built on cmdb_ci_service or a CI class, so risks inherit the service hierarchy and criticality. Business Service profiles let a single risk statement roll up across every supporting CI without duplicating risk records.
What's the difference between a policy and a policy statement?
The policy (sn_grc_policy) is the governing document; policy statements (sn_compliance_policy_statement) are the individually testable requirements inside it, and controls are created from statements against entities.
How do you scope a phased IRM rollout?
Phase 1 policy and compliance on one authority document, phase 2 risk management with a single scoring framework, phase 3 continuous monitoring indicators, phase 4 vendor and business continuity. Each phase must produce audit-usable evidence before the next starts.
Which IRM work belongs in Flow Designer vs. script?
Orchestration, approvals, task creation, and cross-module handoffs go in Flow Designer. Scripts are for indicator result computation, scoring overrides, and data transforms — anything that must return a value rather than route work.
What KPIs prove the IRM program is working?
Control test coverage and pass rate, indicator breach mean-time-to-remediate, percentage of risks with current assessments, issue aging, and the share of controls monitored continuously rather than attested.

  1. 1. Risk Assessment methodology — inherent, residual, and target

    “Walk me through how IRM computes a risk score from inherent to residual on a sn_risk_risk record.”

    How to answer

    • Inherent risk = likelihood × impact, scored BEFORE controls are applied.
    • Residual risk = inherent risk reduced by the effectiveness of mapped controls (sn_compliance_control).
    • Target risk is the appetite the business will tolerate — set on the risk framework, not the risk record.
    • Assessment templates (sn_risk_assessment_template) standardize the question set so scores are comparable across BUs.

    Reference script

    var risk = new GlideRecord('sn_risk_risk');
risk.get(riskSysId);
var inherent = risk.likelihood * risk.impact;
var ctrlAgg  = new GlideAggregate('sn_compliance_m2m_control_risk');
ctrlAgg.addQuery('risk', riskSysId);
ctrlAgg.addAggregate('AVG', 'control.effectiveness');
ctrlAgg.query();
ctrlAgg.next();
var eff = parseFloat(ctrlAgg.getAggregate('AVG','control.effectiveness')) || 0;
var residual = inherent * (1 - eff/100);
gs.info('inherent=' + inherent + ' residual=' + residual);

    Pitfall

    Multiplying effectiveness percentages across controls (compounding) instead of averaging — it produces unrealistically low residuals and fails audit review.

  2. 2. Control testing — attestation vs. continuous monitoring

    “When would you choose continuous monitoring over scheduled attestation for a SOX control?”

    How to answer

    • Attestation = a human asserts the control worked over a period; cheap to configure, weak as evidence.
    • Continuous monitoring = an indicator (sn_grc_indicator) queries the source system on a schedule and writes a result.
    • SOX IT general controls (access reviews, change management) belong in continuous monitoring — indicators on sys_user_group, change_request.
    • Indicator templates make the script reusable across entities; the result populates issue records when thresholds break.

    Reference script

    // sn_grc_indicator script — orphan admin accounts
var gr = new GlideRecord('sys_user_has_role');
gr.addQuery('role.name', 'admin');
gr.addQuery('user.active', true);
gr.addQuery('user.last_login_time', '<', gs.daysAgo(90));
gr.query();
result = gr.getRowCount();   // indicator writes 'result'
// > 0 → automatic GRC issue under the mapped control

    Pitfall

    Returning a boolean from the indicator script — the engine expects the 'result' variable as a number. Booleans get coerced to 0/1 and silently miss thresholds.

  3. 3. Profile types — what an entity actually is

    “A client wants risks scoped to business services AND vendors. How do you model that in IRM?”

    How to answer

    • Profile types (sn_grc_profile_type) define WHAT is being assessed — Business Service, Vendor, Process, Application.
    • Profiles (sn_grc_profile) are the instances — each row is one assessable entity, pointing at a profile type and a source table.
    • Risks, controls, and issues attach to profiles, not directly to source records — that's the indirection that lets one risk apply to many entities.
    • Vendor risk uses the sn_vdr_risk_asmt module which extends profile + assessment with tiering logic.

    Reference script

    // Create profile for a business service
var prof = new GlideRecord('sn_grc_profile');
prof.initialize();
prof.profile_type = businessServiceTypeSysId;
prof.table        = 'cmdb_ci_service';
prof.document     = serviceSysId;
prof.insert();
// Now risks/controls map to prof.sys_id, not the CI directly

    Pitfall

    Attaching risks straight to cmdb_ci or core_company records — it bypasses the profile layer and breaks the entity hierarchy reports that execs rely on.

  4. 4. Issue & remediation workflow — closing the loop

    “What happens after an indicator breach creates an issue? How does remediation tie back?”

    How to answer

    • Indicator breach → sn_grc_issue auto-created, linked to the failing control and profile.
    • Issue routes to the control owner; remediation tasks (sn_grc_remediation_task) hold the actual work.
    • Tasks can spawn change_request or incident records via Flow Designer for cross-module coordination.
    • Issue closure requires evidence — attached doc or linked test result — before state can move to Closed/Resolved.

    Reference script

    // Flow Designer step: when issue.state = Closed
if (current.state == 3 && !current.evidence_attachment) {
  current.setAbortAction(true);
  gs.addErrorMessage('Attach evidence before closing.');
}

    Pitfall

    Letting the indicator re-fire and spawn duplicate issues — set 'create issue only if open issue does not exist' on the indicator, or you'll drown the GRC team in noise.

Ten architect-level scenario questions

These are the design-judgement questions that separate an IRM architect from an IRM admin. Each one gives the recommended answer, a genuine alternate approach with its trade-off, and the pitfall that ends the interview early.

  1. Scoring framework design

    5. The business wants a 1–5 risk matrix, internal audit wants a 1–10 monetary scale. How do you design the framework?

    Two stakeholder groups score risk on incompatible scales, and both need to appear in the same executive heat map.

    Recommended answer

    • Pick one canonical scale on the risk framework (sn_risk_framework) and store all scores in it — normalization at read time is what breaks reporting.
    • Model the monetary view as impact criteria (sn_risk_criteria) with band definitions mapped onto the canonical 1–5 impact levels, so audit's dollar thresholds drive the score rather than living beside it.
    • Expose the monetary figure as a separate read-only field for reporting; it is an attribute of the risk, not a second scoring dimension.
    • Lock the matrix behind a change-controlled update set — rescoring history is unusable if the matrix silently changes.

    Alternate approach

    If the two groups genuinely assess different risk registers (operational vs. financial), run two frameworks and reconcile only at the entity-hierarchy roll-up. Defensible, but it doubles calibration effort and needs an explicit mapping table.

    Pitfall

    Letting each BU define its own likelihood labels. The heat map then aggregates numbers that mean different things, and the first audit finding is against your framework.

  2. Data model & entity population

    6. Profiles are being created manually and drift from reality. How do you fix the entity layer?

    5,000 CIs exist but only 300 profiles, many pointing at retired services.

    Recommended answer

    • Replace manual creation with entity filters: a condition on the source table (for example cmdb_ci_service where operational_status = Operational) attached to the profile type.
    • Let the scheduled entity-population job create and retire profiles, so profile lifecycle follows CI lifecycle automatically.
    • Use the entity hierarchy (parent/child profile relationships) so a risk on a parent business service rolls down without duplicating risk records.
    • Keep an exception list for profiles that must exist without a CI — vendors, processes — under their own profile type rather than loosening the filter.

    Alternate approach

    For a CMDB that is not yet trustworthy, populate profiles from the Application Service or Service Portfolio layer first — far fewer records, curated ownership — and expand to CI classes once CMDB health scores clear your threshold.

    Pitfall

    Filtering on a field that CMDB Discovery rewrites nightly. Profiles then churn, and every churn resets assessment history.

  3. Control architecture

    7. One SOX control applies to 40 applications. Do you create 40 controls?

    The compliance team is copy-pasting controls per application and test evidence is fragmenting.

    Recommended answer

    • Create one policy statement, then let control generation create one control per entity — 40 controls, but generated and governed from a single statement.
    • Test the control once per entity where evidence is entity-specific; use a shared indicator with an entity-scoped query when the evidence is queryable.
    • Map controls to the statement, never entity-to-entity, so a statement change re-flows to every generated control.
    • Use control objectives to group the 40 into one reportable line for the audit committee.

    Alternate approach

    Where a control genuinely operates centrally (a single change-approval gate), attach it to a parent process profile and let entity inheritance cover the children. Fewer records and one test — but only defensible if the control truly executes once.

    Pitfall

    Answering 'one control, 40 entities' with no inheritance model. Interviewers are checking whether you know evidence has to be attributable per entity.

  4. Continuous monitoring at scale

    8. Your nightly indicators now take six hours and overlap the backup window. How do you tune them?

    400 indicators, most written as GlideRecord loops with getRowCount().

    Recommended answer

    • Convert counting indicators to GlideAggregate — a COUNT aggregate replaces a full row walk and is the single biggest win.
    • Stagger indicator schedules by control family instead of running one blanket job, and set realistic frequencies: access reviews monthly, change controls weekly.
    • Push entity-scoped indicators to an indicator template with a parameterized query so one compiled script serves many entities.
    • Index the queried columns on the source table, and cap lookbacks with a bounded date window rather than an open-ended query.

    Alternate approach

    For very high-volume sources, compute the metric outside IRM (a scheduled job writing to a summary table, or an external data warehouse) and have the indicator read the pre-aggregated row. Fast and cheap, at the cost of an extra freshness dependency to document.

    Pitfall

    Leaving getRowCount() on an unindexed table and blaming the platform. Also: returning a value without assigning to the result variable, which records a silent zero.

  5. Third-party / vendor risk

    9. How do you architect vendor risk so tiering drives assessment depth?

    1,200 suppliers, and the team is sending the same 200-question assessment to all of them.

    Recommended answer

    • Model vendors as their own profile type sourced from core_company, with tier derived from data criticality, spend, and service dependency.
    • Use assessment templates per tier — tier 1 gets the full questionnaire plus evidence requests, tier 3 gets an attestation-only short form.
    • Trigger reassessment from events (contract renewal, breach notification, tier change) rather than a fixed annual cycle alone.
    • Feed findings back as risks and issues against the vendor profile so they appear in the same register as internal risk.

    Alternate approach

    Where a third-party risk-exchange feed is available, import external ratings as an indicator on the vendor profile and reserve questionnaires for tier 1 and anomalies. Cuts effort sharply, but you must document the external methodology for auditors.

    Pitfall

    Tiering on spend alone. A low-spend vendor with production data access is a tier 1 risk, and that is exactly the follow-up question.

  6. Audit defensibility

    10. An external auditor asks you to prove a control was effective in Q2. What do you show them?

    The control passed, but the auditor wants the trail, not the status field.

    Recommended answer

    • Show the control test result record for the Q2 period with its attached evidence, tester, and date — the status field alone is never the answer.
    • Show the indicator results for the period with the query definition version, proving what was actually measured.
    • Show the audit history on the control and risk records for any mid-period scoring or ownership change.
    • Show issue and remediation-task records for any breach, including closure evidence, to demonstrate the loop closed.

    Alternate approach

    Where the volume is large, produce a period report from the Audit Management module (engagement + audit tasks) that pre-binds the evidence, instead of walking records live. Cleaner for the auditor, but it needs the audit module implemented and maintained.

    Pitfall

    Allowing controls to be closed without evidence, or allowing evidence attachments to be deleted. Both make the whole period unauditable regardless of pass rate.

  7. Access & segregation of duties

    11. How do you stop a control owner from marking their own control effective?

    GRC roles were granted broadly during rollout and now segregation of duties is a finding.

    Recommended answer

    • Separate the roles: control owner maintains the control, an independent tester or approver records the test result.
    • Enforce with an ACL on the test-result table plus a data policy preventing the tester field from equalling the owner.
    • Use the delegated-development-free path: no scripted ACL where a role and a condition suffice — scripted ACLs on GRC tables are the hardest thing to audit later.
    • Report the exceptions as an indicator so violations surface as issues rather than being blocked silently.

    Alternate approach

    Where headcount makes independent testing impossible, keep self-testing but require a compensating approval step in Flow Designer with the exception documented against the control. Honest and auditable; blocking outright would just push work off-platform.

    Pitfall

    Relying on UI policy to hide the field. Anything enforced only in the client is not a control, and the interviewer will ask about the REST API path.

  8. Legacy migration & upgrades

    12. You inherit an instance on the legacy sn_grc_risk table. How do you move to IRM Advanced?

    Years of scoring history, custom fields, and reports built on the old table.

    Recommended answer

    • Map the legacy model first: risk statements, entity references, scoring fields, and every custom field's real usage — a surprising share is dead.
    • Stand up the new framework (sn_risk_definition, criteria, sn_risk_risk) in a sub-production instance and migrate a representative slice before committing.
    • Migrate history as closed assessment records rather than rewriting current scores, so trend reporting survives without falsifying prior-period data.
    • Rebuild reports against the new tables and retire the old ones deliberately — leaving both live guarantees two versions of the truth.

    Alternate approach

    For instances with thin history, cut over cleanly: freeze the legacy register read-only for audit reference and start the new register from the current assessment cycle. Fastest path, but you lose in-tool trend continuity.

    Pitfall

    Migrating scores without migrating the scoring framework they were produced under. The numbers then look comparable and are not.

  9. Cross-module integration

    13. How should GRC remediation interact with Change and Incident?

    Remediation tasks are being duplicated as change requests by hand.

    Recommended answer

    • Keep sn_grc_remediation_task as the system of record for the GRC obligation, and spawn change_request or incident from it via Flow Designer with a stored back-reference.
    • Drive GRC task state from the linked record's closure, not the reverse — the operational record is where the work happens.
    • Carry the control and profile references onto the change so the audit trail links the fix to the requirement.
    • Never auto-close the GRC task on change closure without an evidence check; closure state and evidence are separate gates.

    Alternate approach

    If the change process is heavy and remediation is mostly configuration, keep remediation entirely in GRC tasks and reference changes only where a CI is touched. Less overhead, but you must be able to explain the boundary to audit.

    Pitfall

    Two-way state sync between GRC tasks and change requests. It loops, and it hides which record is authoritative.

  10. Executive reporting

    14. The CRO says the heat map is green but they don't believe it. How do you diagnose it?

    Aggregate residual risk looks healthy while incidents keep occurring.

    Recommended answer

    • Check assessment currency first: green driven by stale assessments is the most common cause, so report percentage of risks assessed within the cycle alongside the score.
    • Check control effectiveness sourcing — effectiveness asserted by attestation with no test result inflates every residual downstream.
    • Check entity coverage: risks scored only on the assessed 300 profiles while 5,000 entities exist means the map is green by omission.
    • Add a data-quality indicator on the register itself so the program monitors its own inputs.

    Alternate approach

    Present a dual view — residual risk next to a confidence score derived from assessment age, evidence quality, and coverage. It reframes the conversation honestly, though it needs executive buy-in to introduce a second number.

    Pitfall

    Defending the number instead of the inputs. Senior interviewers are testing whether you treat a risk score as evidence or as output of a data pipeline you own.

Keep going

IRM sits on top of platform fundamentals — ACLs gate risk visibility, Flow Designer drives remediation. Tighten those next, or practice the risk-scoring math and GRC tables hands-on.

IRM practice trackGlossary topicsFlow Designer prep