Don’t be Caught Unawares: How to Preserve Audit Evidence when Decommissioning a System!

Imagine you are beginning your company’s annual SOC 2 examination. As your team begins providing evidence for the systems currently in use, your auditor notices that one of the key applications was decommissioned and replaced midway through the audit period. When the auditor requests artifacts from the retired system, your initial reaction may be, “Why would we need to provide evidence for a system that no longer exists?”

The answer is straightforward: while the system may no longer be part of the current environment, it was used to support critical business processes during the period under examination. Auditors, clients, and other stakeholders will still want assurance that the system was appropriately secured and that key controls operated effectively while it was in use. Evidence such as privileged user listings, authentication configurations, change management documentation, monitoring records, and other control artifacts may be necessary to demonstrate that the system’s environment remained secure and compliant prior to its retirement.

This is where many organizations encounter challenges. System decommissioning efforts are often focused on data migration, contract termination, infrastructure retirement, and operational transition, while the preservation of audit evidence receives less attention. Unfortunately, once a system has been retired, access to critical configurations, reports, tickets, logs, and supporting documentation may be lost entirely.

Retiring a system does not eliminate the need to support historical control operations. Organizations must still be able to demonstrate that security, operational, and compliance controls functioned effectively throughout the audit period in its entirety. Proactively preserving audit evidence should be a high priority in every decommissioning effort. Below are the actions organizations should consider to reduce the risk of unexpected audit findings after decommissioning a legacy system.

Audit Evidence to Preserve Before It’s Too Late

To avoid the risk that artifacts related to a legacy system are lost, organizations should capture and retain key audit evidence before a system is sunset. This may include system configurations, access control settings, monitoring dashboards, reports, change documentation, tickets, approvals, training records, and other artifacts needed to demonstrate that controls were operating effectively prior to decommissioning. Preserving this evidence helps maintain audit readiness and provides stakeholders with assurance that the legacy environment remained secure and well-controlled throughout its lifecycle.

Access Controls: The Most Overlooked Evidence Category

When sunsetting a legacy system, organizations often focus heavily on retaining financially relevant records and overlook access controls. After all, why should they care about the access to a system that no longer exists? While the legacy system may not be part of the future state, an organization’s clients, auditors, and other stakeholders will still want assurance that the system was secure during its most recent use, especially during the transition to a new system. Below is the access control evidence that should be retained.

• Privileged Users: The company must demonstrate that the users with access to perform administrative actions within the legacy system were appropriate during and prior to the decommissioning. Inappropriate access may have led to an unintentional (or intentional) loss or corruption of data.
• Population of Users, Roles, and Permissions: Maintaining information about the users with access to the legacy system will be important for data mapping as well as setting up roles and permissions in the replacement system. Understanding the segregation of duties within the legacy system will also be beneficial to illustrate that conflicting roles and responsibilities are avoided within the new system.
• User Access Reviews: While retaining a list of users from the legacy system partially addresses the risk that inappropriate users had access towards the end of its lifecycle, the performance of a user access review during the fiscal year provides additional assurance that access was evaluated for appropriateness. Additionally, access reviews not only review users for appropriateness based on roles and responsibilities, but also check whether they have a status as current personnel.
• Roles Matrix: Where possible, management should export the legacy systems’ roles, permissions, definitions, mappings, etc., to leverage this information for the replacement system as well as to provide auditors and other stakeholders with more information around the role assignments prior to the decommissioning.
• Passwords and Multifactor Authentication: The company must demonstrate that the legacy system previously had strong password requirements and, where applicable, multi-factor authentication implemented to protect the confidentiality and integrity of its data.

Financial Transactions & System Configurations

Before decommissioning a system, financial transaction records and associated audit trails should be retained, archived, and made accessible in accordance with legal, regulatory, business, and audit retention requirements. Maintaining access to financial transaction records when decommissioning a system is important for several business, audit, legal, and operational reasons:

• Financial Records: Auditors often need to examine historical financial transactions to verify revenue and expense recognition, account balances and reconciliations, approval and authorization evidence, and compliance with regulations and accounting standards. If the records are unavailable after a system is retired, the organization may be unable to provide sufficient audit evidence, which can result in audit findings or qualified opinions.
• Financial System Configurations: Companies may also need to preserve critical system configurations and rules, such as the following:
  • 3-way matching rules (PO, receipt, invoice)
  • 2-way matching rules (PO, invoice)
  • Invoice tolerance thresholds
  • Duplicate invoice detection settings
  • Vendor approval workflows
  • Payment approval workflows
  • Delegation of authority (DOA) rules
  • Spending limits by role or department
  • Multi-level approval workflows
  • Escalation rules
  • Chart of accounts structure
  • Account mappings
  • Journal entry approval workflows

Change Management

As part of the legacy system decommissioning process, an organization should also consider how to illustrate that the change management process was operating effectively over the past fiscal year. As the change process can include multiple systems, modules, and supporting documentation, the company should retain the following:

• Population of Changes: Management must maintain the population of changes performed prior to the legacy system decommissioning. This may include a population from a project management tool, SharePoint, code repository, etc.
• Change Documentation: The organization will need to maintain any documentation for the changes associated with the legacy system. This may include the overarching parent ticket, child ticket, development evidence, code scanning, testing, approvals, and any other relevant change details.
• System Configurations: In order to gain assurance that the legacy system changes followed the appropriate system development lifecycle, management may need to obtain systematic evidence of branch protections or other configurations that enforced documentation, testing, approvals, segregation of duties, etc.

Vendor Management: What to Preserve Before Ending a Contract

What should an organization consider when discontinuing a system that is completely managed by a third-party? Can they forgo retaining audit evidence since they are not directly responsible for that system? Unfortunately, certain audit evidence must still be retained prior to ending a contract with a SaaS or other third-party hosted system.

Auditors, clients, and other stakeholders will want to gain assurance that the system used to provide the organization’s services was properly secured during the past fiscal year or report period. Once the contract with the third-party ends, access to the vendor, its systems, and supporting evidence may be limited or unavailable. The following audit evidence should be retained so the company can demonstrate that critical security risks were addressed:

• Vendor Security Reports: Most commonly, auditors will expect that the organization performed a review of the third-party’s SOC 2 report to validate that the report was unqualified and that all complementary user entity controls were addressed. It may also be helpful for the company to assess other types of security reports (SOC 1, PCI, HIPAA, etc.) prior to ending the contract with the vendor.
• Vendor Risk Assessments: An organization should maintain any new or recurring vendor risk assessments to demonstrate that they evaluated security controls during the period that the third party’s application was in use. The company’s stakeholders will want assurance over whether the vendor had a business continuity plan or disaster recovery plan implemented, what certifications they had obtained, if they performed backups, etc.

System Operations

Even if you plan to transition your system operations controls to a replacement system, auditors will still want to gain assurance that these same processes were implemented prior to the decommissioning of the legacy system(s). The following audit evidence should be retained for your end-user devices, servers, and compute resources, network infrastructure, virtual machines, and cloud resources:

• Backups: If the legacy system or tool hosts critical backups, the organization should capture systematic configurations showing the backup schedule (frequency and type of backup) and retention period, as well as a list of backups, where possible.
• Patching, Encryption, Antivirus, and Lockout: If the legacy system(s) provide enterprise device management (EDM) services such as encryption, patching, antimalware, or lockout restrictions, the organization should capture these systematic configurations before decommissioning the system. Additionally, the organization should consider exporting a list of enrolled devices to demonstrate that these configurations were applied to the company’s IT assets.
• Privileged Users: For any legacy applications supporting system operations, such as backup tools, EDM tools, SIEMs, etc., management should capture the privileged users with access to these tools. The auditors will want to gain assurance that only appropriate personnel had access to change the configurations or device enrollment for these systems before decommissioning.

Monitoring Tools: Capturing Evidence Before the Dashboard Goes Dark

What happens when the system being decommissioned is a monitoring tool? Before retiring the tool, an organization should capture screenshots of key dashboards, alerts, and configurations, as well as summary monitoring reports, where applicable. These artifacts will demonstrate that monitoring activities were performed during the period under review, provide evidence of the systems and events being monitored, and illustrate that risks related to system health were appropriately addressed. Auditors and other stakeholders will want to understand how critical systems were monitored for availability, confidentiality, and integrity criteria. Below are some examples of the types of data that should be captured prior to sunsetting a monitoring tool.

Monitoring Dashboards & Alerts

If the legacy system is a monitoring tool, management will want to capture evidence of the tool’s dashboards and alert rules demonstrating the types of data that were being monitored. This may include the following criteria:

Alert Notifications

Prior to the monitoring system’s decommissioning, an organization should capture the notification configurations for a sample of alerts. This may include evidence that a user, group, or members of an on-call team are notified via email, internal communication tool, text, pager, or application dashboard when a critical event occurs. In addition to evidence alert configurations, the organization should consider retaining a sample of actual alerts (i.e., don’t be too hasty to delete alert emails or pings) before your auditors have a chance to inspect them.

Error Resolution

Auditors and other stakeholders will also want to gain assurance that, prior to decommissioning the legacy system, a process was in place to review and remediate monitoring event errors and anomalies. An organization should retain documentation demonstrating that monitoring errors were resolved, either through an automated re-run or manual intervention. For manual intervention, this may include tickets, internal communication tool communications, or email communications.

Supporting Tools That Still Require Audit Evidence

If the sunsetting system isn’t one of the organization’s critical applications, but rather a tool supporting internal processes, should audit evidence still be retained? While the answer depends on the nature of the tool or application, it is worth noting that even some of the smaller, standalone, or internally-facing tools can be critical in regard to audit evidence. Below are some examples of these tools and the associated evidence that may be required for an audit:

• Ticketing System: Onboarding, transfer, or offboarding tickets
• Network Security Tool: VPN configurations or TLS / SSL configurations
• Training Tool: Security, data security, or privacy training records
• Internal Communication Tool: Error alerts and resolution, access approvals, or change release notifications
• Risk Management / GRC Tool: Documented risk assessments or security due diligence assessments
• SharePoint, Intranet, or Drive: Policies, procedures, forms, board meeting minutes
• Human Resource Information System (HRIS) Tool: Background checks, policy acknowledgements, competency evaluations, offer letters, or NDAs

Although internally facing and supporting applications may not be considered business-critical systems, they often contain important records and evidence needed to support audits, compliance reviews, and regulatory requirements. Prior to decommissioning these tools, organizations should evaluate the nature of the information they contain and proactively retain any relevant audit evidence, documentation, configurations, approvals, training records, policies, risk assessments, or personnel records. Failure to preserve this information may result in an inability to demonstrate control operation, support compliance obligations, or provide requested evidence during future audits.

Before You Pull the Plug: A Final Word on Preserving Key Audit Evidence

Decommissioning a system involves far more than migrating data and retiring technology; it also requires preserving the audit evidence needed to demonstrate that security, operational, financial, and compliance controls were functioning effectively throughout the system’s lifecycle. Organizations should proactively identify and retain critical records related to access controls, financial transactions, change management, vendor oversight, system operations, monitoring activities, and supporting business processes before a legacy system is retired. By preserving this evidence, companies can continue to satisfy audit, regulatory, and stakeholder requirements, reduce compliance risk, and avoid the challenges of reconstructing historical control evidence after access to the legacy system is no longer available.

Preparing to decommission a system? Linford & Co’s auditors have helped teams identify what evidence to capture before a legacy system goes dark. Contact us to learn how we can support your next audit or explore our audit services to see how we can help.