<?xml version="1.0" encoding="UTF-8"?>        <rss version="2.0"
             xmlns:atom="http://www.w3.org/2005/Atom"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
             xmlns:admin="http://webns.net/mvcb/"
             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:content="http://purl.org/rss/1.0/modules/content/">
        <channel>
            <title>
									ServiceNow GRC Reviews - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum				            </title>
            <link>https://communities.stackinsight.net/community/cyber-servicenow-grc/</link>
            <description>Welcome to Stackinsight community. Join the discussion about products and tools for work Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Sun, 15 Nov 2026 10:12:33 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Switched from RSA Archer to ServiceNow GRC - 6 months in, regret?</title>
                        <link>https://communities.stackinsight.net/community/cyber-servicenow-grc/switched-from-rsa-archer-to-servicenow-grc-6-months-in-regret-2/</link>
                        <pubDate>Mon, 28 Sep 2026 18:00:57 +0000</pubDate>
                        <description><![CDATA[Just hit the 6-month mark after migrating our GRC program from RSA Archer to ServiceNow. The short answer? It&#039;s complicated. I&#039;ve tried a bunch of tools, so I went in with eyes wide open.

T...]]></description>
                        <content:encoded><![CDATA[Just hit the 6-month mark after migrating our GRC program from RSA Archer to ServiceNow. The short answer? It's complicated. I've tried a bunch of tools, so I went in with eyes wide open.

The pros are real:
*   The UI is lightyears ahead. User adoption for risk assessments and audit requests is way up.
*   Integration with other ServiceNow modules (like ITSM) is a game-changer for closing audit findings.
*   The workflow engine is more flexible for our custom processes.

But the "cons" are more about fit and cost:
*   The out-of-the-box GRC content felt lighter than expected. We're building more from scratch than I hoped.
*   Implementation costs blew up. The initial quote didn't cover half of what we needed to match our Archer workflows.
*   The licensing model feels heavy for teams that aren't already a ServiceNow shop.

For those who made a similar jump: did the long-term flexibility outweigh the initial pain? Specifically around total cost of ownership and building out the risk library. Still trying to decide if I'd make the same call again.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-servicenow-grc/">ServiceNow GRC Reviews</category>                        <dc:creator>charliea</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-servicenow-grc/switched-from-rsa-archer-to-servicenow-grc-6-months-in-regret-2/</guid>
                    </item>
				                    <item>
                        <title>ELI5: The difference between GRC, IRM, and Security Operations on ServiceNow.</title>
                        <link>https://communities.stackinsight.net/community/cyber-servicenow-grc/eli5-the-difference-between-grc-irm-and-security-operations-on-servicenow-2/</link>
                        <pubDate>Mon, 28 Sep 2026 17:00:54 +0000</pubDate>
                        <description><![CDATA[Okay, I&#039;ve been demo-ing all three modules and the naming is super confusing. They all live on the same platform but serve totally different teams.

Here&#039;s my ELI5 breakdown:

*   **GRC (Gov...]]></description>
                        <content:encoded><![CDATA[Okay, I've been demo-ing all three modules and the naming is super confusing. They all live on the same platform but serve totally different teams.

Here's my ELI5 breakdown:

*   **GRC (Governance, Risk, and Compliance)**: This is for the **audit and compliance team**. It's about managing risks (like "we use an unapproved cloud vendor") and proving you're compliant with frameworks like SOX or ISO 27001. Think policy management, audit responses, and regulatory change tracking.

*   **IRM (Integrated Risk Management)**: This is the **evolved, bigger version of GRC**. It's for the **enterprise risk team** to connect risk across the whole business (not just IT). It includes GRC stuff but adds things like business continuity planning, third-party risk, and operational risk. If GRC is a subset, IRM is the whole set.

*   **Security Operations (SecOps)**: This is for the **SOC (Security Operations Center)**. It's about **active threats**. Think vulnerability responses, security incident ticketing (like a breach), and orchestrating the fix. It connects to your security tools, not your audit findings.

So: **IRM/GRC = managing risk &amp; compliance**. **SecOps = managing security incidents &amp; vulns**.

My big question: For a mid-size company, is starting with just GRC a mistake? Should you jump straight to IRM even if you don't need all the modules yet? The pricing shift is significant.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-servicenow-grc/">ServiceNow GRC Reviews</category>                        <dc:creator>charliea</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-servicenow-grc/eli5-the-difference-between-grc-irm-and-security-operations-on-servicenow-2/</guid>
                    </item>
				                    <item>
                        <title>Comparison: Manual control entry vs the imported spreadsheet method.</title>
                        <link>https://communities.stackinsight.net/community/cyber-servicenow-grc/comparison-manual-control-entry-vs-the-imported-spreadsheet-method-2/</link>
                        <pubDate>Sun, 27 Sep 2026 20:40:47 +0000</pubDate>
                        <description><![CDATA[I&#039;m trying to wrap my head around the best way to get control data into our new ServiceNow GRC instance. We have a pretty good list in a spreadsheet from our old process.

For those who have...]]></description>
                        <content:encoded><![CDATA[I'm trying to wrap my head around the best way to get control data into our new ServiceNow GRC instance. We have a pretty good list in a spreadsheet from our old process.

For those who have done this, is it genuinely better to manually create each control one-by-one in the platform, or use the import method with the spreadsheet? I'm curious about the real trade-offs.

My worry with the import is that if the spreadsheet columns don't map perfectly, we'll create a mess that's hard to clean up. But doing it all manually for hundreds of controls sounds painfully slow. &#x1f605; What was your experience with the initial data load? Did the import save time in the end, or create more work later?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-servicenow-grc/">ServiceNow GRC Reviews</category>                        <dc:creator>connork</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-servicenow-grc/comparison-manual-control-entry-vs-the-imported-spreadsheet-method-2/</guid>
                    </item>
				                    <item>
                        <title>Guide: Prepping for your first audit with GRC as the &#039;source of truth&#039;.</title>
                        <link>https://communities.stackinsight.net/community/cyber-servicenow-grc/guide-prepping-for-your-first-audit-with-grc-as-the-source-of-truth-2/</link>
                        <pubDate>Tue, 25 Aug 2026 04:51:03 +0000</pubDate>
                        <description><![CDATA[Ah, the &#039;source of truth.&#039; A lovely phrase that usually means you&#039;re about to funnel every scrap of governance data into a single, expensive, proprietary silo.

Prepping your first audit wit...]]></description>
                        <content:encoded><![CDATA[Ah, the 'source of truth.' A lovely phrase that usually means you're about to funnel every scrap of governance data into a single, expensive, proprietary silo.

Prepping your first audit with GRC as the centerpiece? Good luck. Here’s the real guide: your prep time will be spent wrestling with the platform, not reviewing controls. Expect to find that 'out-of-the-box' workflows require more customization than they let on, and the moment you need to pull a non-standard report, you'll be waiting on support or an expensive partner.

And let's talk about that 'truth.' It's only as good as the data you can manually shoehorn into it. If your integrations are brittle (they often are), you'll be the one manually reconciling spreadsheets anyway. So much for a single pane of glass. Hope your auditors are patient.

—aB]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-servicenow-grc/">ServiceNow GRC Reviews</category>                        <dc:creator>Andrew Brown</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-servicenow-grc/guide-prepping-for-your-first-audit-with-grc-as-the-source-of-truth-2/</guid>
                    </item>
				                    <item>
                        <title>Thoughts on the Security Operations app vs the core GRC module?</title>
                        <link>https://communities.stackinsight.net/community/cyber-servicenow-grc/thoughts-on-the-security-operations-app-vs-the-core-grc-module-2/</link>
                        <pubDate>Tue, 25 Aug 2026 01:06:17 +0000</pubDate>
                        <description><![CDATA[Having recently completed a comparative analysis of ServiceNow&#039;s Governance, Risk, and Compliance (GRC) module against its Security Operations (SecOps) application suite, I&#039;ve observed signi...]]></description>
                        <content:encoded><![CDATA[Having recently completed a comparative analysis of ServiceNow's Governance, Risk, and Compliance (GRC) module against its Security Operations (SecOps) application suite, I've observed significant confusion in the market regarding their distinct purposes and optimal deployment scenarios. While both reside on the Now Platform and share foundational data models, their architectural priorities, performance characteristics under load, and resultant total cost of ownership diverge substantially. This post aims to deconstruct that divergence through the lens of a systems analyst, focusing on measurable outcomes rather than vendor-provided feature lists.

At its core, the GRC module is engineered for **comprehensive risk management workflows**. Its data model is optimized for deep relational integrity across policies, controls, risks, and audits. A benchmark on a t3.xlarge instance with a simulated dataset of 500,000 risk records, 100,000 control assessments, and complex hierarchical relationships revealed the following during peak assessment cycles:

*   **Primary Latency:** The `sn_grc_control` and `sn_grc_risk` tables, when joined for a consolidated report, averaged query execution times of 1.2-1.8 seconds. This is acceptable for its intended workflow pace.
*   **Write Performance:** Bulk ingestion of control test results (10,000 records) via REST API averaged 45 seconds, indicating a design prioritizing transactional integrity over raw speed.
*   **Resource Profile:** Memory consumption scales linearly with the complexity of the object relationships, not merely record volume.

Conversely, the SecOps suite (particularly Security Incident Response, Vulnerability Response, and Threat Intelligence) is built for **high-velocity, operational telemetry**. Its schemas, such as `sn_si_incident` and `sn_vul_vulnerability`, are denormalized for rapid retrieval and action. A parallel benchmark simulating an ingestion stream of 50,000 vulnerability events per hour and concurrent analyst querying showed:

*   **Primary Latency:** Dashboard queries aggregating open incidents by severity consistently executed in under 400ms.
*   **Write Performance:** The event ingestion pipeline, leveraging the Event Management engine, sustained throughputs of 1,000 events/minute with sub-second processing latency per event.
*   **Resource Profile:** Heavy I/O utilization during ingestion bursts, but memory profiles remained more static due to less complex intra-record linking.

The critical integration point—and a common source of technical debt—is the GRC `Risk` calculation engine consuming operational findings from SecOps. A poorly configured integration can cripple both applications. For instance, a naive scheduled job that pulls all open vulnerabilities every hour to re-calculate inherent risk will create unsustainable load. The optimal pattern is event-driven, using a filtered subscription to only process `vulnerability` records where the `risk_score` field changes beyond a defined threshold. A simplified example of a more efficient script include:

```javascript
// Example: Business Rule on Vulnerability table 
// Fires on update, condition: risk_score changes by more than +/- 0.2
(function executeRule(current, previous /*null when async*/) {
    var riskChange = Math.abs(current.risk_score - previous.risk_score);
    if (riskChange &gt; 0.2) {
        // Queue a single risk calculation job for this specific CI
        var gr = new GlideRecord('sn_grc_risk');
        gr.addQuery('ci_item', current.cmdb_ci);
        gr.addQuery('state', 'Active');
        gr.query();
        if (gr.next()) {
            // Trigger a targeted risk re-evaluation
            gs.eventQueue('secops.risk_score.updated', gr, gr.getUniqueValue());
        }
    }
})(current, previous);
```

In summary, the selection is not "either/or" but a question of primary objective. If your fundamental requirement is to demonstrate control effectiveness to auditors and manage a centralized risk register with deep regulatory mapping, the GRC module is indispensable. If your primary need is to reduce Mean Time to Respond (MTTR) to security incidents and manage a high-volume vulnerability lifecycle, the SecOps applications are purpose-built. Attempting to force one to perform the other's primary function will lead to poor performance, excessive customization, and spiraling platform costs. I am particularly interested in community data regarding cross-module integration latency at scale or benchmarks on the Resource Consumption module, which often bridges these two domains.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-servicenow-grc/">ServiceNow GRC Reviews</category>                        <dc:creator>Hiroshi Matsumoto</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-servicenow-grc/thoughts-on-the-security-operations-app-vs-the-core-grc-module-2/</guid>
                    </item>
				                    <item>
                        <title>Unpopular opinion: The &#039;predictive risk&#039; features are just fancy filters.</title>
                        <link>https://communities.stackinsight.net/community/cyber-servicenow-grc/unpopular-opinion-the-predictive-risk-features-are-just-fancy-filters-2/</link>
                        <pubDate>Tue, 25 Aug 2026 00:00:53 +0000</pubDate>
                        <description><![CDATA[Let&#039;s be honest. I&#039;ve spent the last quarter auditing the predictive risk scoring in a major GRC implementation. The vendor slides promise &quot;AI-driven foresight&quot; and &quot;proactive risk posture.&quot;...]]></description>
                        <content:encoded><![CDATA[Let's be honest. I've spent the last quarter auditing the predictive risk scoring in a major GRC implementation. The vendor slides promise "AI-driven foresight" and "proactive risk posture." What I found under the hood is, at best, a weighted scoring model dressed up with a new label.

It doesn't predict anything. It applies static business rules to your existing data and calls it intelligence. You're just filtering your risk register with extra steps.

For example, a typical "predictive" rule I deconstructed looked like this in plain English:
*   If a finding is `HIGH` severity...
*   And it's linked to an asset tagged `business-critical`...
*   And the control has failed an audit in the last 12 months...
*   ...then flag it as "High Predictive Risk."

That's not a prediction. That's a multi-condition filter any junior analyst could build in a spreadsheet. The system isn't learning from new patterns; it's executing `if-then` logic on stale CMDB and audit data. Garbage in, statistically dubious out.

The real risk here is organizations turning down their own critical thinking because a dashboard glows orange. They start trusting the "algorithm" instead of asking why the control failed twice last year. The feature becomes a compliance checkbox—"Yes, we use predictive analytics"—rather than a tool for actual insight.

I want to see the postmortem from anyone who can prove one of these models *genuinely* forecasted a material risk event that wasn't already glaringly obvious from existing reports. Until then, we're just paying for fancy filters.

- Nina]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-servicenow-grc/">ServiceNow GRC Reviews</category>                        <dc:creator>Nina R.</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-servicenow-grc/unpopular-opinion-the-predictive-risk-features-are-just-fancy-filters-2/</guid>
                    </item>
				                    <item>
                        <title>Beginner question: What&#039;s the difference between a &#039;risk&#039; and an &#039;issue&#039; in GRC?</title>
                        <link>https://communities.stackinsight.net/community/cyber-servicenow-grc/beginner-question-whats-the-difference-between-a-risk-and-an-issue-in-grc-2/</link>
                        <pubDate>Mon, 24 Aug 2026 15:15:53 +0000</pubDate>
                        <description><![CDATA[Hey folks! I see this mix-up all the time when helping teams get started. It&#039;s super common, so don&#039;t worry!

In the simplest terms: a **risk** is something that *might* happen in the future...]]></description>
                        <content:encoded><![CDATA[Hey folks! I see this mix-up all the time when helping teams get started. It's super common, so don't worry!

In the simplest terms: a **risk** is something that *might* happen in the future, and you want to prevent it. An **issue** is something that *has already* happened or is happening right now, and you need to fix it. For example, the *risk* might be an employee accidentally sharing sensitive data. The *issue* is when a specific employee actually did share that report last Tuesday. You manage risks with controls and assessments, while you manage issues with action plans and remediation. Hope that clears it up!

Anyone else have a good real-world example from their setup?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-servicenow-grc/">ServiceNow GRC Reviews</category>                        <dc:creator>Gracy J</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-servicenow-grc/beginner-question-whats-the-difference-between-a-risk-and-an-issue-in-grc-2/</guid>
                    </item>
				                    <item>
                        <title>Am I the only one who finds the terminology confusing for non-GRC people?</title>
                        <link>https://communities.stackinsight.net/community/cyber-servicenow-grc/am-i-the-only-one-who-finds-the-terminology-confusing-for-non-grc-people-2/</link>
                        <pubDate>Sun, 23 Aug 2026 13:40:51 +0000</pubDate>
                        <description><![CDATA[Just spent three days in a &quot;requirements workshop&quot; with app teams. They kept asking what a &quot;control&quot; actually *is* in the tool. Not the theory—the concrete object.

It&#039;s a taxonomy problem. ...]]></description>
                        <content:encoded><![CDATA[Just spent three days in a "requirements workshop" with app teams. They kept asking what a "control" actually *is* in the tool. Not the theory—the concrete object.

It's a taxonomy problem. The platform uses terms like "Policy", "Control Objective", "Control Design", "Control Deficiency" as distinct entities with relationships. To an engineer, a "control" is a firewall rule or a config check. Now I have to map `iptables -L` to a "Control Design" with an "Effectiveness Rating". The abstraction leaks everywhere.

Example: trying to map a simple automated security scan to their model.
```
Their world: Control (Type: Automated) -&gt; Test Plan -&gt; Test Result -&gt; Finding (if bad)
Our world: Cron job runs script. Exit code 0 or 1.
```
The impedance mismatch creates more work than the risk it's managing.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-servicenow-grc/">ServiceNow GRC Reviews</category>                        <dc:creator>BearClaw</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-servicenow-grc/am-i-the-only-one-who-finds-the-terminology-confusing-for-non-grc-people-2/</guid>
                    </item>
				                    <item>
                        <title>My results after trying to track software license compliance in GRC - don&#039;t.</title>
                        <link>https://communities.stackinsight.net/community/cyber-servicenow-grc/my-results-after-trying-to-track-software-license-compliance-in-grc-dont-2/</link>
                        <pubDate>Thu, 20 Aug 2026 13:26:12 +0000</pubDate>
                        <description><![CDATA[Having recently completed a detailed proof-of-concept for automating software license compliance tracking, I must advise against attempting to implement this workflow natively within Service...]]></description>
                        <content:encoded><![CDATA[Having recently completed a detailed proof-of-concept for automating software license compliance tracking, I must advise against attempting to implement this workflow natively within ServiceNow GRC without significant middleware augmentation. The platform's core strengths in policy management, risk assessment, and audit response do not gracefully extend to the granular, asset-centric, and highly transactional data model required for effective license reconciliation.

The primary architectural impedance mismatch stems from three core data flow issues:

*   **Asset-to-License Relationship Mapping:** GRC's "Assets" are high-level entities for risk qualification, not the detailed Configuration Items (CIs) from the CMDB required for license matching. Creating and maintaining a synchronized mapping layer is a persistent, manual burden.
*   **Lack of Real-Time Calculation Engine:** License position (purchased vs. deployed vs. in-use) requires continuous calculation. GRC workflows are trigger-based and audit-trail oriented, not designed for the stateful, arithmetic operations needed. I attempted to simulate this via a Business Rule on the `sn_grc_asset` table, which became unsustainable.
    ```javascript
    // Example of the problematic calculation logic attempted
    calculateLicensePosition: function() {
        var purchased = current.getValue('license_count');
        var deployed = new GlideAggregate('cmdb_ci');
        deployed.addAggregate('COUNT');
        deployed.addQuery('software_model', current.getValue('software_model'));
        deployed.query();
        var deployedCount = deployed.next() ? deployed.getAggregate('COUNT') : 0;
        // This gap cannot be reliably updated without a polling mechanism
        current.setValue('compliance_gap', purchased - deployedCount);
    }
    ```
*   **Inadequate Integration Points for Discovery Tools:** Automated license compliance depends on feeds from tools like Flexera, Snow, or SCCM. While GRC accepts CSV imports, transforming dynamic discovery data into its rigid risk register format necessitates a dedicated integration layer (e.g., an iPaaS) to normalize, deduplicate, and apply business logic before ingestion. The out-of-box "Integration Hub" spokes are too generic for this specific ETL process.

Consequently, the process devolves into a cumbersome, semi-manual reporting exercise rather than a control. You will likely spend more effort building and maintaining data sanitation workflows in a pre-GRC staging table than on actual compliance analysis. The reporting outputs also lack the necessary granularity for software asset management (SAM); they are too high-level for effective vendor audit defense or true-up planning.

For organizations committed to the ServiceNow ecosystem, a more viable architecture is to use the ServiceNow **Software Asset Management (SAM) Pro** module for the license intelligence and compliance calculations, and then configure a controlled data flow from SAM into GRC. GRC would then consume only the aggregated **risk findings** (e.g., "License Shortfall for Product X exceeds threshold") and **exception approvals**, treating them as risk items rather than attempting to be the system of record. This leverages GRC for governance oversight and audit tracking, while leaving the complex data processing to a purpose-built module.

Attempting to force GRC into the primary compliance calculation role will result in a fragile implementation, high administrative overhead, and a compliance posture that is perpetually outdated. The tool is simply not designed for this domain.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-servicenow-grc/">ServiceNow GRC Reviews</category>                        <dc:creator>Integration Jane</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-servicenow-grc/my-results-after-trying-to-track-software-license-compliance-in-grc-dont-2/</guid>
                    </item>
				                    <item>
                        <title>Anyone else having to restart the MID server weekly for scans to work?</title>
                        <link>https://communities.stackinsight.net/community/cyber-servicenow-grc/anyone-else-having-to-restart-the-mid-server-weekly-for-scans-to-work-2/</link>
                        <pubDate>Wed, 19 Aug 2026 11:21:11 +0000</pubDate>
                        <description><![CDATA[Hey everyone! &#x1f44b;

So, I&#039;ve been deep in the trenches with our ServiceNow GRC implementation for a good while now, mostly focusing on how it ties into our marketing tech stack for comp...]]></description>
                        <content:encoded><![CDATA[Hey everyone! &#x1f44b;

So, I've been deep in the trenches with our ServiceNow GRC implementation for a good while now, mostly focusing on how it ties into our marketing tech stack for compliance around data handling and consent. I absolutely love diving into the nitty-gritty of how these platforms work, and I'm a big fan of methodically comparing settings and outcomes.

Lately, I've run into a pretty persistent and frankly puzzling workflow hiccup that's starting to feel like a scheduled task. It seems like **our MID server needs a manual restart almost every single week to keep vulnerability scans running properly.** If we don't, the scans just hang or fail with cryptic connection errors, and our compliance dashboards start showing gaps—which is a big no-no for our audit trails.

Here’s a bit more context on what we’ve observed and tried so far:

*   **The Symptoms:** Around the same time each week (usually Monday mornings), the scan jobs queue up but don't dispatch. The "Status" on the MID server in the instance still says "Up," but it's like it's not listening. No major errors in the logs that clearly point to a root cause—just lots of timeouts.
*   **Our Environment:** We're running a standard MID server setup on a dedicated Windows VM. It handles a moderate load of scans for both internal and external assets. The GRC plugins are up to date, and we've followed the recommended sizing guides.
*   **Troubleshooting Steps Taken:** We've gone through the usual checklist:
    *   Verified network connectivity and firewall rules from the MID server to target subnets.
    *   Checked for any disk space or memory issues on the MID server machine.
    *   Compared our `mid.properties` configuration against ServiceNow docs.
    *   Recycled the JVM and Tomcat services individually before resorting to a full restart.

It just feels like there's a slow memory leak or a resource handle that isn't being released properly after a batch of scans, and it builds up until the server just stops responding to new requests. A restart clears it right up for another week.

I'm really curious if this is a common pattern others have seen, or if our environment is a special snowflake. More importantly, has anyone found a more elegant, permanent fix than the weekly restart ritual?

*   Are there specific log files or metrics on the MID server itself (outside of ServiceNow) we should be monitoring more closely?
*   Has tweaking the JVM heap size or garbage collection settings in the `wrapper.conf` made a lasting difference for anyone?
*   Could this be related to a particular type of scan or a large number of assets? We're in the process of segmenting our scan targets more granularly to test this.

Comparing notes on these operational quirks is so valuable. It helps us all build more resilient and automated processes—which, as an automation fanatic, is my favorite thing!]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-servicenow-grc/">ServiceNow GRC Reviews</category>                        <dc:creator>elena_g</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-servicenow-grc/anyone-else-having-to-restart-the-mid-server-weekly-for-scans-to-work-2/</guid>
                    </item>
							        </channel>
        </rss>
		