ServiceNow Governance, Risk and Compliance for Insurance

Governance, risk and compliance for insurance is the set of controls an agency or carrier uses to meet state requirements on licensing, producer oversight, commissions and complaints. This page explains how to separate requirements from controls and evidence, map one control to many states and test whether a control works.

State Insurance Department Compliance Frameworks

Every state insurance department has regulatory requirements. Licensing, producer oversight, suitability reviews, and consumer complaint handling are mandated. Some states conduct periodic examinations; others conduct targeted reviews of specific practices. Your GRC system must track applicable state requirements and maintain evidence that your organization complies with each. When a state audit begins, you should produce documented evidence of compliance across all regulated areas.

A GRC strategy in insurance must be organized by requirement type and state. A compliance task might be: “Conduct annual suitability review of all currently appointed producers.” Another might be: “Review and document all customer complaints received in the period.” These recurring tasks are logged in your GRC system with owners and deadlines. When completed, evidence is attached: a list of producers reviewed, documentation of the suitability determinations, or a complaint log with resolutions.

Producer Oversight and Appointment Tracking

Regulators expect you to maintain detailed records of each producer you appoint, including background checks, suitability determinations, carrier appointments, and any disciplinary action. ServiceNow’s GRC module can centralize this documentation. A risk register tracks known issues with producers: complaints, compliance violations, or performance problems. Remediation tasks address identified issues: retraining, commission clawback, or termination. Progress is tracked and documented. When an auditor reviews your producer oversight controls, you produce a report showing oversight activities and how issues were resolved.

Appointment termination is also tracked. If a producer is terminated for cause, documentation of the reason, the investigation, and the appeal (if applicable) is maintained in your GRC system. This creates an audit trail for regulators reviewing your disciplinary procedures.

Commission Audit and Compensation Controls

Commission payment is a high-audit-risk area. Regulators examine whether commissions are accurate and comply with appointment agreements. Your GRC system should include a compliance task for regular commission audits. Periodically—typically quarterly or semi-annually—a sample of commission payments is reviewed to verify accuracy. The audit documents the payments reviewed, any discrepancies found, and corrections made. If a discrepancy is found (an overpayment or underpayment), a remediation task is created to correct the payment.

Some agencies conduct continuous monitoring. Commission payment files are reviewed against appointment agreements automatically; variances trigger alerts. These controls are documented in your GRC system as compensating controls: you are monitoring continuously rather than conducting periodic audits. Either approach is defensible; the key is documenting what controls exist and monitoring their effectiveness.

Consumer Complaint Management and Investigation

Insurance regulations require documentation of customer complaints and resolutions. A complaint might be about commission, claim handling, product suitability, or producer conduct. Each complaint must be investigated, documented, and resolved. ServiceNow can manage this workflow: a complaint is reported, an investigation case is created, findings are documented, and corrective action (if needed) is taken. Your GRC system tracks complaint themes: are certain producers generating more complaints? Are certain products problematic? Analysis of complaint data helps identify systemic issues.

Regulatory reporting requirements vary by state. Some states require notification of significant complaints or investigation findings. Your GRC system should flag complaints that meet state-specific reporting thresholds and trigger reporting tasks. Compliance teams use these flags to ensure timely notification.

Continuing Education and Competency

Many states require producers to maintain continuing education credits. Your GRC system can track compliance. Annual compliance verification tasks verify that each licensed producer has completed required education. Noncompliance is escalated immediately. Some states also allow you to require additional training beyond state minimums. A risk register might identify that producers are making unsuitable product recommendations; a remediation task requires all producers to complete a product suitability course. Completion is tracked and documented in your GRC system.

Competency reviews—periodic evaluations of a producer’s sales practices, customer complaints, and compliance record—can be tracked as GRC tasks. A producer with high complaint rates might be required to complete retraining or is reassigned to lower-risk activities. The review and remediation plan are documented, creating evidence of your competency management process.

Audit Preparation and Documentation

Comprehensive documentation is your best defense during an audit. A well-organized GRC system allows you to produce audit evidence quickly: producer appointment files, suitability review documentation, complaint handling records, commission audit results, and compliance task completion records. Auditors can request a specific time period (e.g., “all producer appointments and suitability reviews from recent years”) and receive a coherent report rather than having to piece together data from multiple systems. This reduces audit burden and demonstrates a high level of control maturity.

Audit findings should be tracked in your GRC system. Each finding documents what was found, the deadline for remediation, the remediation plan, and verification of completion. When the auditor conducts a follow-up, you produce a report showing all findings have been addressed. This organized, documented response to audit findings strengthens your relationship with regulators and reduces follow-up scrutiny.

Risk Register and Regulatory Change Management

A risk register in your GRC system identifies and tracks business and compliance risks. Regulatory changes—new state rules, carrier requirements, or industry standards—are added to the register as risks with mitigation plans. For example, a state legislative change requiring additional disclosure on certain products is a risk until your processes are updated. A task is created to review the new requirement, update your systems and procedures, and train staff. Completion is documented. Your risk register shows that you identify regulatory changes and respond proactively.

Separating a control from the tasks and evidence around it

The reader for this section is the compliance lead who builds and maintains the control library for an insurance agency or carrier. Many GRC libraries become hard to use for one reason: the same object is called a requirement in one place, a control in another, and a task in a third. A state rule, a carrier requirement, the thing the business does to meet it and the record it leaves are four separate layers. Keep them separate from the start and each one can change without disturbing the others. The policy and compliance management page for insurance describes the state-by-state regulatory frameworks that insurers have to manage.

The control is the object most worth getting right. If the control is written as a list of tasks, every change in the task list looks like a change in the control, and the library stops telling a reviewer what the business is committed to. Write the control as an outcome the business commits to, and let the tasks be the way that outcome is delivered each period. The policy and evidence planning guidance covers the same separation from the evidence side.

Mapping one control to many state requirements

An agency that operates in many states faces many versions of the same obligation. Writing a separate control for each version is tempting, because it looks thorough, and it can multiply the work without improving the outcome. The better approach is to map many requirements to one control where the outcome and the evidence are the same, and to add a state parameter for the details that differ, such as the review period or the form of the record.

1. List every requirement that touches the same business activity, such as producer appointment, and group them by the outcome they demand.
2. Write one control per outcome, with its owner and the evidence it must produce.
3. Map each state requirement to the control that meets it, and record any state that adds a condition.
4. Create a separate control only where the obligation, the timing or the evidence form genuinely differs.
5. Review the mapping when a state changes its rule, and record the change against the affected controls rather than creating new ones by default.

Testing whether a control works, not just whether it ran

A control task that is completed on time can still be ineffective. A producer review that ticks every box but never looks at complaint history misses the thing the regulator cares about. Operating effectiveness is tested by selecting a sample of completed tasks and checking whether the outcome the control promises was actually achieved. Choose the sample across regions and across producers with different risk profiles, not only the easy cases. Record the test, the sample, the exceptions and the conclusion, and keep the test separate from the task it examines so that one person does not grade their own work. The audit management page for insurance covers the audit lifecycle, including planning, scope and sampling.

Evidence that holds up when the file is requested

When an examiner asks for evidence, the question is rarely whether a task exists. It is whether the evidence is dated, attributable, complete and linked to the requirement it answers. A screenshot of half a screen fails the completeness test. A signed list with no date fails the dating test. A file named with a producer’s full personal details and stored in a shared folder fails the access test. Define these criteria in the control standard, and check a sample of evidence against them each period.

Failure modes in controls that have run for years

Long-running controls drift in predictable ways. Owners change roles and the control keeps running under a name that no longer means anything to the team. Two workflows create the same task for the same producer, and the duplicate is closed by the wrong person. Evidence is attached to the wrong producer record because two producers share a surname, which is a data quality problem with a compliance consequence. A risk register item is closed when the mitigating task finishes, without a check that the residual risk has actually fallen. The periodic review of the library should look for each of these, not only for missing tasks. Risk items that depend on a mitigating task are better tracked in the operational risk register guidance, which covers keeping each risk’s condition, owner, response and acceptance authority visible.

When a state variance is not worth its own control

A simple test helps. If the obligation, the timing and the evidence are the same, one control with a state parameter is enough. If any of the three differs in a way that changes what the business must do, a separate control is justified. The test prevents the library from growing with variants that nobody can tell apart, and it gives the control owner a reason to say no to the next request for a new control that duplicates an existing one.

Questions about GRC control design in insurance

Where does ownership sit for a control covering several states?

One named owner for the control as a whole, and a state-level delegate for each region where the parameters differ. The owner is accountable for the outcome, and the delegate is accountable for the local tasks. Make both names visible on the control record, so that a gap in one region does not become nobody’s problem.

How often should the control library itself be reviewed?

Review it when a requirement changes, when an owner changes, and on a fixed cycle that the compliance committee agrees. The fixed cycle catches the drift that no single change triggers, such as an owner who has moved on without a handover.

Can an automated control still count as human oversight?

An automated check can operate a control, but the oversight of the check is a human responsibility. Someone must review the exceptions the automation raises, test whether the check still matches the rule, and decide what to do when it does not. Record that human review as its own control, so the examiner can see who is accountable.

What if a regulator asks for a control we never wrote down?

Be honest about the gap. Document what the business actually does, assess whether it meets the requirement, and open a remediation item if it does not. A documented gap, treated seriously, is far easier to defend than a control that appears on paper only after the request arrives.