I'm part of a healthcare SaaS company with about 60 employees, and we have a SOC 2 Type II audit coming up in just three weeks. The audit requires us to showcase that critical workflows across our production systems are running smoothly and are being monitored. Our auditor expects both our modern web portal and an outdated desktop billing application we inherited to comply, but there's a significant challenge because the desktop app doesn't have an API and hasn't been updated in years. Our engineering team assessed the situation and determined that we'll need to set up two distinct testing frameworks, one for the web and another for the desktop app, which would double our setup and maintenance workload. We even brought in an offshore QA contractor, but they reached the same conclusion. With the audit fast approaching, we're facing a coverage gap for this legacy application. Has anyone dealt with cross-environment testing for both web and legacy desktop apps in SOC 2 audits? What strategies have worked for you?
5 Answers
We faced something similar with a legacy desktop application that lacked an API but still needed to be part of the audit. Instead of overhauling the app, we focused on setting up controls around it, such as documenting user workflows, access restrictions, and implementing system-level monitoring like logs and execution tracking. In some cases, we even used automation tools to simulate critical workflows for audit proof. The goal was to show that our surrounding controls ensured reliability and security, regardless of the app’s age. Are you considering using compensating controls or attempting to integrate automation/testing into the app?
One option you might consider, although not the best, is using AutoHotkey to automate interactions with the legacy app. It can be tricky, but it might give you some quick wins in the interim.
You're really in a tough spot with that old billing app! Instead of dealing with unreliable UI automation, consider creating a 'Governance Shell' around the application. By emphasizing OS-level logging and system trackers, you can present a solid trail of evidence for the auditor without modifying that legacy code. It should help you cover your bases for the audit without compromising on quality.
If possible, you might want to prioritize migrating that legacy app to your web stack. Sure, it’s a significant effort, but it can save you headaches in the long run.
I've had success building workflows around legacy applications by focusing on the output they generate, like invoices, and accessing the underlying database. Rather than wrestling with an outdated GUI, automating SQL queries and getting data from the database has proven much simpler. If you can track down the database, duplicating it for audits and working from there can save you a lot of trouble.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures