Cherwell EOL and Data Retention: The Audit-Readiness Guide for Public Companies

26 Feb 2026 · By Brian Parks, CEO — Synapse Software
Former Senior Software Engineer at Cherwell Software (2017–2020)

What Cherwell End of Life Actually Means for Your Data

When Ivanti announced Cherwell Service Management’s end of life on October 31, 2023, most IT teams focused on the obvious question: what platform do we migrate to?

That’s the right question. But it’s not the only one.

The question that gets far less attention — and creates far more risk for public companies — is this: what happens to years of historical data that still lives in your Cherwell database after the platform goes dark?

Cherwell EOL means no more security patches, no more bug fixes, no more vendor support. On-premise customers can technically keep their Cherwell instances running after December 31, 2026. But “technically running” and “audit-ready” are not the same thing.

For public companies subject to SOX, and for organizations in regulated industries subject to HIPAA, GLBA, NERC CIP, or ITAR, the historical data in Cherwell doesn’t stop being regulated just because the platform stops being supported.

The retention clock keeps ticking. The compliance obligations remain. And the auditors will still come.

Why This Matters More for Public Companies

Every company listed on a US stock exchange is subject to the Sarbanes-Oxley Act. SOX isn’t optional. It isn’t industry-specific. If you’re publicly traded, SOX applies to you.

Here’s where Cherwell enters the SOX conversation.

IT Change Records Are in SOX Scope

SOX Section 802 and the SEC’s implementing rule (Rule 2-06 of Regulation S-X) require that audit-related records be retained for seven years after the auditor concludes an audit or review. For the companies themselves, SOX Sections 103(a) and 404 require that management maintain and produce records supporting internal controls over financial reporting — and in practice, the 7-year standard has become the baseline retention period for SOX-related records across the industry. For IT departments, this means change management records that support financial reporting systems are squarely in scope.

Think about what lives in your Cherwell database: change requests for ERP systems, incident records involving financial applications, access control documentation, ITGC (IT General Controls) evidence captured through ITSM workflows. These aren’t just operational records — they’re SOX evidence.

When your external auditor asks for documentation of IT controls during a SOX 404 assessment, those records need to be accessible, searchable, and intact. Not buried in a database on an unsupported platform. Not exported to CSV files where ticket relationships, attachments, and audit trails have been stripped away.

The Penalties Are Not Theoretical

SOX Section 802 (codified at 18 U.S.C. §1519) makes it a federal crime to knowingly destroy, alter, or falsify records with the intent to obstruct an investigation — punishable by up to 20 years imprisonment and fines. Section 906 adds criminal penalties for executives who certify financial reports they know don’t comply: up to $1 million and 10 years for knowing violations, and up to $5 million and 20 years for willful violations. Companies that fail to comply can face fines up to $25 million, potential delisting from public stock exchanges, and regulatory enforcement actions.

No public company wants to explain to the SEC why their IT change records supporting financial reporting are trapped on an unpatched, unsupported platform with no vendor behind it.

The “Keep It Running” Fallacy

Some teams assume they can just keep their Cherwell instance alive after EOL. On paper, this works — your on-premise server doesn’t care about Ivanti’s support calendar. But consider what “alive” actually costs:

A minimum Cherwell license runs approximately $15,000 per year (based on a five-license minimum). Add infrastructure costs for the server, database maintenance, security monitoring for an unpatched application, and the staff time to keep it running — and you’re looking at a conservative $40,000 per year in total cost of ownership. Over the three years it takes to clear your SOX retention window, that’s approximately $120,000 to maintain read-only access to historical data.

And that’s the optimistic scenario. After December 2026, Ivanti won’t sell you new licenses at all. The “keep it running” option has an expiration date.

The Regulation-by-Regulation Breakdown

SOX is the baseline for every public company. But depending on your industry, you likely have additional regulatory layers that compound the data retention problem.

HIPAA (Healthcare Organizations)

• Retention requirement: 6 years for compliance documentation, per 45 CFR §164.316(b)(2)(i). This is the federal floor — state medical record retention laws often require 7 to 10 years, and CMS requires 10 years for Medicare cost-report providers.
• What’s in your Cherwell database: Incident records containing references to protected health information (PHI), change management records for PHI-handling systems, access logs, service desk tickets with patient information, HR cases involving healthcare workers.
• The risk after EOL: PHI sitting on an unpatched platform isn’t just a retention problem — it’s a breach risk. If OCR investigates, “we knew the platform was unsupported” is a difficult position to defend. In 2024, OCR completed 22 enforcement actions — the second highest in its history — and collected over $9.9 million in settlements and civil monetary penalties. HIPAA penalty tiers range from $145 to $73,011 per violation (as of the January 2026 inflation adjustment), with an annual cap of $2,190,294 per identical provision.

GLBA (Financial Institutions)

• Retention requirement: GLBA itself doesn’t specify a retention period, but it requires financial institutions to maintain comprehensive information security programs under the Safeguards Rule. Adjacent SEC rules (17a-4 for broker-dealers) and banking regulations impose specific retention periods, typically 3 to 7 years depending on record type.
• What’s in your Cherwell database: Service desk tickets containing customer nonpublic information (NPI), change management records for financial systems, access logs, incident records related to financial data processing.
• The risk after EOL: The GLBA Safeguards Rule requires “reasonable safeguards” over customer data. An unsupported platform receiving zero security patches is, by definition, not a “reasonable safeguard.” Penalties reach $100,000 per violation for institutions and $10,000 per violation for officers and directors, with criminal penalties of up to 5 years imprisonment for willful violations.

NERC CIP (Energy and Utilities)

• Retention requirement: Ongoing — security controls must be commensurate with threats to critical infrastructure assets.
• What’s in your Cherwell database: Change management records for CIP-regulated assets, incident records, evidence supporting CIP-005 (electronic security perimeters), CIP-007 (systems security management), and CIP-010 (configuration change management).
• The risk after EOL: NERC CIP penalties can reach $1 million per day per violation. (NERC Rules of Procedure and CIP standards govern compliance.) Running an unsupported ITSM platform that manages change records for critical infrastructure assets is the kind of finding that auditors are specifically looking for.

ITAR/CMMC (Defense and Aerospace)

• Retention requirement: ITAR requires 5 years of records for export-controlled items. CMMC Level 2 requires demonstrable protection of Controlled Unclassified Information (CUI).
• What’s in your Cherwell database: Change requests involving export-controlled systems, incident records for defense programs, access documentation, any tickets containing CUI.
• The risk after EOL: CUI on an unsupported platform is a CMMC assessment finding. ITAR violations carry criminal penalties up to $1 million per violation. For defense contractors, a CMMC failure doesn’t just mean a fine — it risks contract eligibility.

State Privacy Laws

Regardless of industry, your company’s headquarters location may trigger additional requirements:

• California (CCPA/CPRA): $7,500 per intentional violation, $2,500 per unintentional violation.
• New York (DFS 23 NYCRR 500): Multi-million dollar penalties demonstrated in enforcement actions. The NY SHIELD Act adds data security requirements.
• Texas (TDPSA): Up to $25,000 per violation.
• Massachusetts (201 CMR 17.00): Requires written information security programs covering all systems holding personal data.

State laws increasingly require “reasonable security” over retained personal data. An unpatched, unsupported Cherwell instance containing personally identifiable information is difficult to defend as “reasonable” in any regulatory or litigation context.

The Five Options (and What Each Actually Costs)

Every Cherwell customer facing EOL has essentially five choices for their historical data. Not all of them work for public companies with compliance obligations.

Option 1: Keep Cherwell Running After EOL

• How it works: Maintain your on-premise Cherwell instance indefinitely. No vendor support, no patches, no license renewals after existing agreements expire.
• Cost: $40,000 to $50,000+ per year (license floor, infrastructure, security monitoring, staff time). Over a SOX retention window: approximately $120,000 to $150,000+.
• Compliance status: Increasingly indefensible. Zero patches means growing vulnerability surface. Every audit cycle, the gap between “supported” and “running” widens. Most information security policies and frameworks (ISO 27001, NIST CSF, SOC 2) explicitly require that production systems receive vendor patches. A deliberately unsupported system contradicts these policies.
• Verdict: Expensive and deteriorating. A stopgap, not a strategy.

Option 2: Migrate Everything to the New Platform

• How it works: Move all historical Cherwell data into your new ITSM platform (ServiceNow, Jira, HaloITSM, EasyVista, etc.) during the migration project.
• Cost: $50,000 to $200,000+ depending on data volume, complexity, and customization. Adds significant scope and timeline to an already complex migration project.
• Compliance status: If executed properly, this is compliant — your data lives on a supported, patched platform. But “if executed properly” is doing a lot of heavy lifting. Historical data rarely maps cleanly to a new platform’s data model. Relationships between tickets, attachments, journal entries, and custom business objects can break during transformation. The data may technically exist but lose its operational context — which is exactly what auditors need.
• Verdict: Possible but expensive, risky, and distracting from the migration itself. Most migration partners explicitly exclude historical data from their SOWs because of this complexity.

Option 3: Export to CSV/Flat Files

• How it works: Export Cherwell data to CSV files, PDFs, or a data warehouse before EOL.
• Cost: $15,000 to $40,000 in labor, depending on volume and complexity.
• Compliance status: The data exists, but the context doesn’t. CSV exports strip away the relationships between tickets — the parent/child connections, linked configuration items, embedded forms, journal entries with their chronological audit trail, and file attachments. When an auditor asks for the full change record including approvals, implementation notes, and rollback documentation, a flat CSV file doesn’t provide that. For SOX purposes, the question isn’t just “do you have the data?” — it’s “can you produce it in a form that demonstrates the control environment?” A pile of CSV files with broken relationships doesn’t demonstrate much.
• Verdict: Better than nothing. Not sufficient for serious compliance.

Option 4: Do Nothing and Hope for the Best

• How it works: Let Cherwell die on December 31, 2026. Hope nobody asks for historical records.
• Cost: $0 upfront. Potentially catastrophic later.
• Compliance status: This is the scenario your auditor has nightmares about. It’s March 2027. Your external auditor asks for IT change management records from 2022 supporting a SOX 404 assessment. Your answer is “that data is on a platform we decommissioned.” That’s not a defensible position. It’s a material weakness disclosure. For regulated industries, the math gets worse. HIPAA penalties, GLBA violations, NERC CIP fines — these aren’t theoretical. They’re enforcement actions that happen to organizations that can’t produce required records.
• Verdict: Not an option for public companies.

Option 5: Archive to a Purpose-Built Platform

• How it works: Use a dedicated data archival solution designed specifically for Cherwell databases. Connect the solution directly to your Cherwell database backup — no data transformation, no export, no import. The solution reads the Cherwell data model natively and preserves all relationships, business objects, journal entries, attachments, and security group permissions.
• Cost: A fraction of keeping Cherwell alive. Typically a subscription model without the ongoing infrastructure and licensing costs.
• Compliance status: If the archival solution preserves the complete data structure with all relationships intact, provides searchable access with original form views, maintains audit trails, and runs on a supported platform with current security patches — this satisfies the “accessible, searchable, and intact” requirements across SOX, HIPAA, GLBA, and other regulatory frameworks.
• Verdict: Purpose-built for this exact problem. Solutions like Cortex Archive, designed specifically for Cherwell data archival, connect directly to your Cherwell database backup and present records in the same form layout your team is used to — without requiring any data transformation or migration.

The Audit-Readiness Checklist for Public Companies

Whether you choose to archive, migrate, or maintain your Cherwell data, you need a plan that passes audit scrutiny. Here’s what that plan should include.

1. Inventory Your Cherwell Data by Regulatory Category

Before you can make a retention decision, you need to know what’s actually in your database. Map your Cherwell business objects against your regulatory obligations:

• SOX scope: Change management records supporting financial reporting systems. Incident records for ERP, GL, AP/AR, and other financial applications. ITGC evidence. Access control documentation.
• HIPAA scope: Any ticket containing PHI references. Patient-related incident records. Audit logs for PHI-handling systems.
• GLBA scope: Service desk tickets with customer NPI. Change records for financial data processing systems.
• NERC CIP scope: Change records for CIP-regulated assets. Incident records. Configuration management evidence.
• State privacy scope: Any record containing PII for residents of states with privacy laws (California, New York, Texas, Massachusetts, and others).

This isn’t a theoretical exercise. Your compliance team should be able to produce this inventory if an auditor asks for it.

2. Define Retention Periods by Record Type

Different regulations require different retention windows. Map each category of Cherwell data to its applicable retention period:

Regulation	Retention Period	Applies To
SOX	7 years (SEC Rule 2-06; Sections 103(a), 404)	All US public companies
HIPAA	6 years from creation or date last in effect	Healthcare organizations
GLBA	3–7 years by record type (adjacent SEC/banking rules)	Financial institutions
NERC CIP	Ongoing (controls commensurate with threats)	Energy/utilities
ITAR	5 years	Defense/aerospace
FERPA	No federal period specified; institutions set own policies	Education
State privacy laws	Varies: 3–7 years	All companies with PII

For public companies with multiple regulatory exposures, the longest retention period governs. A publicly traded healthcare company, for example, faces SOX (7 years) and HIPAA (6 years) — so the 7-year SOX window is the binding constraint.

3. Evaluate Your Migration SOW for Historical Data Gaps

If you’re actively migrating from Cherwell to a new ITSM platform, review your Statement of Work carefully. In our experience working with Cherwell customers across dozens of migrations, most migration SOWs explicitly exclude historical data.

The migration partner’s job is to get you live on the new platform. Historical data — with its complex relationships, custom business objects, and legacy form definitions — is rarely in scope. And for good reason: transforming Cherwell’s data model into a completely different platform’s data model is a project in itself.

This means the historical data question is yours to solve, not your migration partner’s. The sooner you recognize this, the more time you have to solve it properly.

4. Test Your Audit Response

Before December 31, 2026, simulate an audit request. Have someone on your team (or an external advisor) make the following requests, as if they were an auditor:

• “Produce all change management records for [financial system] from 2022, including approvals, implementation documentation, and rollback plans.”
• “Show me the incident history for [PHI-handling system] over the past 6 years, with journal entries and resolution documentation.”
• “Demonstrate access control evidence for [customer data system] for the most recent SOX assessment period.”

If you can produce these records quickly, with complete context and intact relationships, you’re audit-ready. If you can’t — or if the process requires manually piecing together CSV exports and database queries — you have a gap.

5. Document Your Retention Strategy

Your auditor will want to see not just that you have the data, but that you have a documented plan for retaining it. This should include:

• Which Cherwell data falls under which regulatory obligations
• How long each category of data will be retained
• Where and how the data is stored (archived platform, server location, backup procedures)
• Who has access and how access is controlled (authentication, security groups)
• How the data will be disposed of when retention periods expire
• How the strategy was approved (executive sign-off, board notification if applicable)

For SOX purposes, this documentation itself becomes part of your control environment. Having a formal, board-approved data retention strategy covering legacy ITSM data demonstrates the kind of governance that auditors look for.

Timeline: What to Do and When

The December 31, 2026 deadline is fixed. Here’s a realistic timeline for getting audit-ready.

Now Through Q2 2026 (March–June)

• Inventory and assess. Map your Cherwell data against regulatory obligations. Identify which business objects are in SOX scope, which contain PHI or NPI, and which support regulated operations. Engage your compliance team in the assessment — this isn’t just an IT exercise.
• Evaluate options. Determine whether you’ll archive, migrate historical data, or maintain the Cherwell instance. Get procurement involved early if you’re evaluating third-party solutions — enterprise procurement cycles can take 60 to 90 days.
• Check your migration SOW. If you’re mid-migration to a new ITSM platform, confirm whether historical data is in scope. If it isn’t (and it usually isn’t), start planning separately.

Q3 2026 (July–September)

• Implement your solution. Whether that’s deploying an archival platform, completing a data migration, or hardening your existing Cherwell environment — this is the execution window. Don’t wait until Q4. Platform deployments, even simple ones, take time for procurement, installation, configuration, user acceptance testing, and sign-off.
• Test audit readiness. Run the simulated audit requests described above. Can you produce complete, contextualized records on demand? If not, iterate.
• Document the strategy. Write and approve the formal data retention policy covering legacy ITSM data. Get executive sign-off. Brief the audit committee if applicable.

Q4 2026 (October–December)

• Final validation. Confirm that your archival or migration solution is production-ready and fully accessible to all authorized users. Verify that security groups and access controls are functioning correctly.
• Communicate to stakeholders. Notify your external auditor that you have a documented plan for Cherwell historical data retention. Proactive communication signals governance maturity and reduces surprise findings.
• Complete Cherwell decommission. With your historical data safely archived or migrated, you can decommission your Cherwell infrastructure with confidence. No more license costs, no more server maintenance, no more security risk from an unpatched platform.

Frequently Asked Questions

Does SOX really apply to IT change records?

Yes. SOX Section 404 requires management to assess and report on the effectiveness of internal controls over financial reporting. IT General Controls (ITGCs) — including change management, access controls, and computer operations — are a standard component of SOX assessments. Change records in your ITSM platform that relate to financial systems are SOX evidence. This is why the PCAOB’s auditing standards specifically include IT controls in the scope of integrated audits.

Can we just export everything to a data warehouse?

You can, but you’ll lose the context that makes the data useful for compliance. Cherwell’s data model uses a relational structure where tickets, journal entries, attachments, approvals, configuration items, and custom business objects are all interconnected. A raw database export or CSV extraction preserves the data but breaks these relationships. When an auditor asks for a change record, they want the complete picture — not a table of records they have to manually reconstruct.

What if we haven’t started planning yet?

You still have time, but the window is narrowing. Archival solutions that connect directly to Cherwell databases can typically be deployed in under 30 days. Full platform migrations of historical data take significantly longer. The biggest risk at this point isn’t the technical implementation — it’s the procurement cycle. If your solution requires legal review, security assessment, and procurement approval, start that process now.

Does our migration partner handle this?

Almost certainly not by default. Review your Statement of Work. Most migration partners scope their work around getting you live on the new platform — not preserving 7+ years of historical data from the old one. If historical data is in your SOW, confirm that it includes preservation of relationships, attachments, journal entries, and audit trails — not just a flat data dump.

What happens to our data after the retention period expires?

Once you’ve exceeded your longest applicable retention period (typically 7 years for SOX), you can — and often should — dispose of the data in accordance with your data retention and destruction policy. Some regulations, including state privacy laws and GDPR, actually require disposal of personal data when the retention purpose has ended. Having a documented disposal procedure is as important as having a retention procedure.

The Bottom Line

Cherwell’s end of life is a platform event. But for public companies, the compliance implications extend years beyond December 31, 2026.

SOX doesn’t care which ITSM platform you used. It cares that you can produce 7 years of IT change records supporting financial reporting — accessible, searchable, and intact. HIPAA doesn’t care that your vendor went away. It cares that PHI is on a system with reasonable security controls. GLBA, NERC CIP, ITAR, and state privacy laws all have the same fundamental requirement: the data must be retained, it must be protected, and you must be able to produce it when asked.

The organizations that treat Cherwell EOL as a data retention event — not just a migration event — are the ones that will pass their next audit without a finding.

As someone who spent years building inside the Cherwell platform, I can tell you: the data model is complex, the relationships between objects are critical, and preserving them matters. For a purpose-built archive that preserves your Cherwell data without migration, see Cortex Archive. Plan accordingly.