Synapse Software
Cherwell EOL and Data Retention: What Australian Organisations Need to Know Before December 2026
The Regulatory Pressure Is Already Here
Australia’s financial regulators have been tightening the screws on information security since the Medibank breach in 2022. APRA’s capital charges, the OAIC’s civil penalty proceedings, the new CPS 230 operational resilience standard. The message is clear: if you hold data, you are accountable for it.
But there is a deadline that has not made it into most compliance teams’ planning: Cherwell Service Management goes end of life on December 31, 2026. And for the hundreds of Australian organisations still running Cherwell, the question nobody is asking is what happens to the historical data that stays behind.
Your migration partner will move your active data. Open incidents, recent changes, current configurations. Everything older stays in the Cherwell database. And after December 31, 2026, that database is sitting on an unsupported platform with no patches, no vendor support, and no clear path to access.
What Lives in Your Cherwell Database That Australian Regulators Care About
Cherwell is not just a ticketing system. At most regulated organisations, it contains:
- IT change management records tied to critical business systems
- Incident records with references to personal information (customer, employee, or patient data)
- Access control and provisioning documentation
- HR case management data with personally identifiable information
- Service request records containing financial or sensitive personal data
- Audit trail logs for IT General Controls
- Custom business objects unique to your organisation’s compliance workflows
If your Cherwell instance touches any of these, you have regulated data that must remain accessible after the platform goes dark.
The Australian Regulatory Landscape
APRA CPS 234: Information Security for Financial Institutions
CPS 234 has been in force since July 1, 2019. It applies to all APRA-regulated entities: banks, credit unions, general insurers, life insurers, private health insurers, and superannuation trustees. That is over 680 entities overseeing more than $9.8 trillion in assets.
The core requirement is straightforward: maintain an information security capability commensurate with the size and extent of threats to your information assets. An unsupported Cherwell instance running after December 2026 with no security patches, no vendor support, and no bug fixes is not commensurate with anything. It is an unmanaged information asset sitting on infrastructure that is actively degrading in security posture.
Key CPS 234 requirements relevant to your Cherwell data:
-
Information asset classification: CPS 234 requires regulated entities to classify their information assets based on criticality and sensitivity. Your Cherwell database contains years of IT change records, incident data, and potentially personal information. After EOL, this asset moves from “managed” to “unmanaged” unless you have a plan.
-
Controls commensurate with threats: The standard requires that controls protecting information assets reflect the threats to those assets. After December 2026, the threat profile of an unpatched Cherwell instance increases every day. The controls available to you (vendor patches, support, bug fixes) drop to zero.
-
Third-party obligations: Where information assets are managed by a third party, CPS 234 requires you to assess that party’s information security capability. When Ivanti stops supporting Cherwell, your third-party relationship with the platform vendor effectively ends. But your data does not disappear. You need a documented plan for what happens next.
-
Incident notification: APRA must be notified of material information security incidents within 72 hours. A data breach on an unpatched, unsupported Cherwell instance would trigger this obligation and raise immediate questions about whether your information security capability was adequate.
APRA does not impose traditional fines under CPS 234. Its enforcement tools are arguably more impactful: enforceable undertakings, additional capital adequacy requirements, restrictions on operations, and formal directions. After the Medibank breach, APRA imposed a $250 million capital adequacy charge. That sends a clear message about how seriously APRA takes information security failures.
CPS 230: Operational Resilience (New as of July 2025)
CPS 230 replaced the previous outsourcing standard on July 1, 2025. It introduces new requirements around operational resilience, critical operations, and material service provider management.
Here is why this matters for Cherwell: existing service provider contractual arrangements must comply with CPS 230 by the earlier of July 1, 2026, or the next renewal date. That is the same year Cherwell goes end of life.
If your organisation has any contractual relationship with Ivanti related to Cherwell, you need to assess that relationship under CPS 230 before the compliance deadline. And if that relationship ends because Cherwell is decommissioned, you need to document what happens to the data that was managed under that arrangement.
CPS 230 also requires organisations to identify critical operations and maintain tolerance levels for disruption. If your ITSM data supports audit readiness, regulatory reporting, or operational continuity, losing access to years of historical records could constitute a disruption to a critical operation.
The Financial Accountability Regime: Personal Liability
The Financial Accountability Regime makes individual executives personally accountable for compliance obligations, including CPS 234. APRA’s June 2025 letter explicitly linked FAR Accountable Person identification to CPS 234 compliance for the first time.
This means the decision about what happens to your Cherwell data is not just an organisational risk. It is a personal accountability issue for whoever is responsible for information security at your organisation.
Privacy Act 1988: The “Reasonable Steps” Standard
Australian Privacy Principle 11.1 requires organisations to take “such steps as are reasonable in the circumstances” to protect personal information from misuse, interference, loss, unauthorised access, modification, or disclosure.
The critical question after December 2026: is running personal data on an unsupported, unpatched platform a “reasonable step” to protect it?
The OAIC has made clear that what constitutes “reasonable” depends on the size of the organisation, the sensitivity of the information, and the potential consequences of a breach. For a large financial institution or government agency holding years of ITSM data that includes personal information, running that data on software with no security patches is difficult to defend as reasonable.
The enforcement landscape has changed dramatically. Following the Medibank breach, Australia amended the Privacy Act to introduce maximum penalties of the greater of $50 million, three times the benefit obtained through the contravention, or 30% of the organisation’s domestic turnover. The OAIC has commenced civil penalty proceedings against Medibank in the Federal Court, alleging interference with the privacy of 9.7 million Australians by failing to take reasonable steps to protect their personal information.
The OAIC’s Corporate Plan for 2024-25 explicitly states that the office is prioritising regulatory action where there is a high risk of harm to the community. Running regulated data on unsupported infrastructure creates exactly that kind of risk.
State Records Acts and Government Obligations
Australian state and territory governments operate under their own records retention legislation:
- NSW: State Records Act 1998 requires government agencies to make and keep full and accurate records and to manage those records in accordance with approved retention and disposal authorities.
- Victoria: Public Records Act 1973 requires government agencies to maintain records in accordance with standards issued by the Public Record Office Victoria.
- Queensland: Public Records Act 2002 requires agencies to make, manage, and preserve public records.
- South Australia: State Records Act 1997 imposes obligations on government agencies to maintain official records.
For government agencies running Cherwell as their ITSM platform, these obligations mean that historical service records cannot simply be abandoned when the platform is decommissioned. The records retention periods specified under each state’s legislation continue regardless of whether the technology that created those records is still supported.
Federal government agencies face similar obligations under the Archives Act 1983, which requires Commonwealth records to be managed in accordance with standards set by the National Archives of Australia.
The Regulatory Summary
| Regulation | Retention requirement | Who it applies to | What is in your Cherwell DB |
|---|---|---|---|
| APRA CPS 234 | Controls commensurate with threats; unsupported platforms create unmanaged risk | All 680+ APRA-regulated entities (banks, insurers, super funds, health insurers) | IT change records, incident logs, access control documentation, third-party records |
| APRA CPS 230 | Operational resilience; service provider contracts must comply by July 2026 | All APRA-regulated entities | Records supporting critical operations, service provider documentation |
| Privacy Act (APP 11.1) | “Reasonable steps” to protect personal information; penalties up to $50M or 30% of turnover | All organisations with $3M+ annual turnover handling personal information | Incident records with personal data, HR cases, service requests with customer/employee PII |
| FAR | Personal accountability for executives on CPS 234 compliance | Senior executives at APRA-regulated entities | All information assets under CPS 234 scope |
| State Records Acts | Vary by state; government agencies must retain and manage records per approved authorities | NSW, VIC, QLD, SA, WA, TAS, ACT, NT government agencies | Service requests, incident reports, change documentation held by government bodies |
| Archives Act 1983 | Commonwealth records managed per National Archives standards | Federal government agencies | All ITSM records created by Commonwealth agencies |
The Four Options (and Why Three of Them Are Bad)
Every Australian organisation dealing with Cherwell end of life has four options for their historical data:
Option 1: Keep Cherwell alive
Maintain a minimum Ivanti license (approximately $15,000 USD per year for 5 seats), plus server infrastructure, patching, and staff time. After December 2026, there will be no security patches and no vendor support. Under CPS 234 and the Privacy Act, running an unsupported platform with regulated data on it is a compliance finding waiting to happen. And the pool of engineers who know Cherwell is shrinking rapidly. In Australia, where the talent market for legacy ITSM platforms is already thin, this problem is acute.
Option 2: Export to CSV or flat files
Write SQL scripts to extract data into spreadsheets. This is the most common approach and the most likely to fail when someone actually needs a record. Flat exports lose form views, relationships between records, attachments, expression-driven fields, and security permissions. When a regulator or auditor asks for the original incident record, a CSV row is not what they expect. The question will be: “Can you produce the original service record from 2024 showing how your team handled this incident, with all linked approvals and attachments intact?” If the answer involves searching through spreadsheets, you have a problem.
Option 3: Migrate all historical data into the new platform
Move everything into ServiceNow or Jira or wherever you are going. Significant professional services cost. Six to eighteen month timelines. Data structure mismatches cause lossy translation. And most migration SOWs explicitly exclude historical data because it is a separate, complex workstream. In Australia, where professional services rates for ServiceNow implementation run $250 to $400 per hour, this option carries a significant price tag for data that will only be accessed occasionally.
Option 4: Do nothing
Let the data go dark when Cherwell shuts down. This violates retention obligations under the Privacy Act, creates CPS 234 exposure for APRA-regulated entities, and leaves government agencies unable to meet their obligations under state records legislation. It also transfers personal liability under FAR to whoever made the call.
There is a fifth approach: preserve the entire Cherwell environment in a read-only archive that maintains the original form views, linked records, attachments, and security groups without requiring an active Cherwell license or any data migration. That is what we built Cortex Archive for Cherwell to do.
What This Means for Your Timeline
December 2026 sounds far away. It is not.
Enterprise procurement in Australia typically takes several months. Government procurement can take six months or longer, particularly for state government agencies subject to panel arrangements and value-for-money assessments. APRA-regulated entities face additional vendor onboarding requirements including security assessments and CPS 234 compliance reviews.
If your organisation needs to evaluate, procure, and implement a data preservation solution before the Cherwell EOL date, the planning needs to start now.
CPS 234 compliance is being actively monitored. APRA conducted an independent tripartite cyber assessment across more than 300 regulated entities and identified six common gaps, including incomplete identification and classification of critical information assets. An unplanned Cherwell database sitting on decommissioned infrastructure is exactly the kind of gap APRA is looking for.
What Australian Organisations Should Do Before December 2026
-
Inventory your regulated data. Which Cherwell business objects contain records subject to the Privacy Act, CPS 234, or state records retention requirements? How many years of history do you have? Which custom objects are unique to your compliance workflows?
-
Check your migration SOW. Ask your migration partner explicitly: is historical data in scope? If it is not (and it usually is not), you need a separate strategy for retaining access to that data.
-
Assess your CPS 230 position. If you have a contractual relationship with Ivanti related to Cherwell, review it under CPS 230 before the July 2026 compliance deadline. Document what happens to the data when that relationship ends.
-
Evaluate your archive options before the deadline. Your retention obligations extend years beyond December 2026. The solution you choose needs to make regulated records accessible, searchable, and intact for the full retention window without depending on unsupported software.
The organisations that handle this well will have their archive strategy in place before the migration is complete. The ones that do not will find out the hard way, the first time an auditor asks for a record they cannot produce.
Frequently Asked Questions
When is Cherwell Service Management end of life?
December 31, 2026. After that date, the platform loses vendor support, security patches, and bug fixes. Cloud customers lose access entirely. On-prem customers can technically continue running, but on an unsupported, unpatched platform.
Does CPS 234 specifically mention ITSM platforms?
CPS 234 does not name specific technologies. It requires APRA-regulated entities to maintain information security capability commensurate with the threats to their information assets. An unsupported ITSM platform containing years of operational and personal data is an unmanaged information asset under CPS 234’s framework.
What is the difference between CPS 234 and CPS 230?
CPS 234 focuses on information security. CPS 230 focuses on operational resilience and service provider management. They overlap when an ITSM platform is both an information asset (CPS 234) and a service provider relationship (CPS 230). The July 2026 CPS 230 compliance deadline for existing service provider contracts coincides with the Cherwell EOL date.
Does the Privacy Act set specific retention periods for ITSM data?
No. The Privacy Act requires organisations to take reasonable steps to protect personal information and to destroy or de-identify it when it is no longer needed. But other obligations (tax records, financial records, employment records, state records legislation) often require you to retain records for six to ten years or longer. The tension between these obligations is the core problem: you must keep the data, but you must also protect it with reasonable security measures. An unsupported platform does not meet that standard.
What happened with the Medibank breach and why does it matter here?
In October 2022, a cyber attack on Medibank exposed the personal information of 9.7 million Australians. The OAIC commenced civil penalty proceedings in the Federal Court in June 2024, alleging Medibank failed to take reasonable steps to protect personal information under APP 11.1. APRA separately imposed a $250 million capital adequacy charge. Following the breach, Australia amended the Privacy Act to increase maximum penalties to the greater of $50 million, three times the benefit obtained, or 30% of domestic turnover. The Medibank case established that the OAIC will pursue significant enforcement action where organisations fail to maintain adequate security over personal information.
Can I just export everything to CSV before the deadline?
You can, but it probably will not satisfy your compliance obligations. Flat exports lose form views, linked relationships between records, attachments, approval chains, and security permissions. When an auditor asks for the original change record with all linked approvals and attachments, a spreadsheet row is not sufficient evidence.
What about organisations outside Australia that have Australian customers?
If your organisation processes personal information of Australian residents, the Privacy Act applies regardless of where you are headquartered. The extraterritorial reach of Australian privacy law means that Cherwell data containing Australian personal information is subject to Australian retention and security obligations.