From Legacy to Audit-Ready [Modernize AS/400 for HIPAA and SOC 2]

Healthcare organizations tend to treat AS/400 compliance risk as a slow burn problem, something to address when resources allow or when an auditor forces the issue. The data suggests that window is closing faster than most teams realize.

256% increase in hacking related breaches in healthcare over five years
(HHS Office for Civil Rights breach reports, 2018 to 2023)

30 to 40% reduction in duplicated compliance effort when HIPAA and SOC 2 controls are shared
(Reported by healthcare IT teams following structured AS/400 modernization programmes)

50% compression in audit preparation timelines, from nearly a year to 4 to 5 months
Achieved by teams that centralized evidence collection and automated log aggregation

These are not abstract trends. They describe the environment that your AS/400 is operating inside today, and the gap between what legacy infrastructure was designed to prove and what auditors now expect to see.

The question is not whether your AS/400 is working. The question is whether it can prove it is working in the way that HIPAA and SOC 2 require, every time someone asks.

Legacy AS/400 in Healthcare: We Know What You're Dealing With

There are a few patterns we have seen consistently across teams using AS/400. Over time, these have become recurring challenges during audits. This section focuses on where those patterns typically emerge and why they matter during audits.

Access: You Know It Is Controlled but You Cannot Always Prove It

In most AS/400 environments, access management was designed for operational needs, not audit scrutiny. The result is a familiar combination: user permissions that are broader than they need to be, role-based segmentation that is limited or informal, and logs that exist but are scattered across systems in formats that are difficult to centralize.

This gap becomes more critical in the current threat landscape. Ransomware attacks targeting healthcare systems have risen by 264% between 2018 and 2023, according to HHS Office for Civil Rights breach reports. When incidents increase at that pace, the ability to clearly demonstrate who accessed what, and when, is no longer optional.

When an auditor asks who accessed a specific patient record last Tuesday, or which users had write access to a billing module during Q3, the answer is technically available somewhere in your environment. But reconstructing it takes hours, sometimes days. An answer that takes days to produce is not an answer that satisfies a HIPAA audit.

We have seen billing teams face situations where claims were sitting in queues with no clear visibility into who touched what, or why a workflow had stalled. During daily operations, that is an inconvenience. During an audit, it becomes a finding.

SOC 2 compounds this further because it requires consistency over time, typically across a six-to-twelve-month observation window. A logging gap in March, an incomplete access review in June, and a permission change that lacked documentation in September are individually manageable. Together, they become a pattern that auditors will flag, and that leadership will need to explain.

PHI: You Know It Is Protected but the Environment Was Not Built for How Protection Is Measured Now

The gap here is rarely about intent. Healthcare organizations running AS/400 environments have generally maintained protections that worked within the logic of their architecture. The issue is that modern compliance frameworks measure protection differently from how legacy systems were built to provide it.

HIPAA expects encryption across all layers, not selectively. It expects access to be controlled at the data level, not just at the network perimeter. It expects breach investigation to be supported by audit trails that can reconstruct exactly what happened, when, and to which records.

AS/400 environments were not designed around these expectations. That does not mean they are unprotectable. It means the controls that exist were designed for a different threat model and a different audit standard. The gap becomes visible not during daily operations, but the first time you try to answer a specific compliance question from a specific auditor.

The Dormant Data Problem That Most Teams Discover Too Late

This is the risk that consistently surprises healthcare organizations because it does not surface in routine operations. It surfaces during audits.

Over time, AS/400 environments accumulate data that no longer serves an active purpose. Billing extracts from retired cycles. EHR exports from applications that were decommissioned. Historical patient datasets retained for reference. Legacy flat files that contain complete PHI from claims runs that finished years ago.

The assumption is usually that because this data is no longer actively used, it carries lower compliance risk. That assumption is incorrect.

In healthcare, dormant PHI is not dormant responsibility. If the data still exists anywhere in your environment, HIPAA still expects you to protect it, control access to it, retain it according to defined policies, and demonstrate what has happened to it. Regulators do not distinguish between live PHI and old PHI when they evaluate safeguards.

Partially retired AS/400 partitions often hold complete PHI datasets that remain accessible through older user profiles or inherited permissions, but are no longer covered by modern logging, centralized monitoring, or current governance practice. There is no active breach. There is no daily exposure. But there is a compliance liability that will become visible the moment someone asks the right question during an audit.

We have seen organizations spend months in remediation cycles not because something went wrong, but because they could not answer basic questions. Who can still access this data? Is that access logged? Can we prove the data has not been altered or copied since the system was retired? When those questions cannot be answered quickly, old data becomes a current liability.

The Compliance Treadmill: Working Harder on the Same Problem Every Cycle

Most healthcare compliance teams are not ignoring these issues. They are working extremely hard. The problem is the nature of the work, and how poorly it scales.

Pulling logs manually across disconnected systems. Reconciling access records by hand. Building evidence packages for HIPAA and then rebuilding essentially the same evidence again for SOC 2 because the collection process was not designed for reuse. Spending months before each audit doing work that should take weeks.

The controls often overlap significantly between HIPAA and SOC 2. The evidence frequently does not, because it was never designed to be shared. That is where effort compounds, and where teams start running audits that feel like they are consuming more capacity each cycle rather than becoming more efficient over time.

This is the clearest signal that the underlying environment needs structural change, not just additional preparation effort.

What Peers Are Actually Doing: Four Paths and When Each One Applies

The organizations that have successfully closed the gap between AS/400 operations and compliance readiness have not followed a single route. They have chosen a path based on where their risk was concentrated, how much disruption they could absorb, and how quickly they needed results. Here is how each approach plays out in practice, framed around the compliance outcomes it delivers.

Path 1: Rehosting

What organizations in this group do is move AS/400 workloads largely as they are into a cloud hosted or virtualized IBM Power environment, without rewriting the core applications. The business logic stays intact. What changes is the infrastructure layer around it.

Moving into a modern hosting environment makes it significantly easier to centralize logging, enforce identity management, implement backup controls, and apply encryption more consistently. Teams that have done this report meaningful improvements in their ability to respond to audit questions quickly, not because the application changed, but because the supporting infrastructure became easier to govern.

This is the right starting point for organizations where audit pressure is high, code risk is high, and the priority is improving control visibility without introducing major application change. It does not solve every long-term issue, but it can move the compliance needle meaningfully in the near term.

The limitation to be honest about is that Rehosting alone does not fix data level access controls, application layer audit trails, or dormant data risks. It creates a better platform for solving those problems but solving them still requires deliberate effort.

Path 2: Replatforming

Organizations that choose this path move applications or data to a more modern operating or database environment while keeping core business logic relatively intact. The typical goal is to reduce dependency on ageing hardware and make data more accessible for monitoring, querying, and integration with security tooling.

For HIPAA readiness, replatforming can make PHI significantly easier to classify, monitor, and trace because the data is now in an environment where modern security tooling can reach it. For SOC 2, it tends to improve consistency around patching, performance, uptime, and evidence collection.

The risk that teams in this group consistently mention is that partial change can expose old assumptions. If data is moved but the control environment is not redesigned around that movement, organizations can create new compliance gaps while attempting to close old ones. Replatforming must be paired with rigorous access validation and logging reviews, or the migration itself becomes an audit risk.

Path 3: Refactoring

This is the path organizations choose when the AS/400 application still provides core business value, but the compliance burden has become too manual and too fragile to sustain. Rather than replacing the application, they rework code and data structures so that security and compliance controls are embedded in the application layer, not just maintained by infrastructure and perimeter controls.

For HIPAA, refactoring typically supports granular audit trails, stronger data level protections, better session monitoring, and more controlled handling of PHI across workflows. For SOC 2, it improves the organization's ability to demonstrate consistent control execution across the six-to-twelve-month observation window that trust services criteria require.

One healthcare organization that took this route had been preparing for SOC 2 annually with a team of four people spending roughly ten to twelve weeks in evidence collection each cycle. After refactoring the core AS/400 billing application to embed logging and access controls directly, that process dropped to under five weeks, with fewer manual steps and significantly higher confidence in the evidence produced.

Path 4: Re Architecting

The Strongest Long Term Compliance Foundation

Re architecting means redesigning legacy applications into modern services, APIs, or modular platforms that better support cloud operations, continuous monitoring, integration, and policy enforcement. It is the most transformative approach, and it requires the most effort.

The compliance payoff is commensurate. Modern architectures give organizations substantially more control over access patterns, event monitoring, encryption enforcement, and system observability. In HIPAA environments, that translates to better protection of ePHI across its full lifecycle. In SOC 2 environments, it creates a control environment that can be continuously monitored and automatically evidenced rather than manually assembled before each audit.

This is typically the right path when compliance pressure, technical debt, and business change are all pointing in the same direction simultaneously. It is not the right starting point for an organization that needs to pass an audit in six months.

The Phased Approach: How Most Organizations Actually Do This

Most healthcare organizations cannot modernize everything at once. The practical path that consistently works combines elements of the above in a deliberate sequence. Rehost the core environment to improve infrastructure level control, archive dormant PHI into a compliant repository, refactor the most compliance sensitive modules, and re architect later when the foundation is stable.

The key insight from organizations that have done this well is that they reduced audit pain early, in the first six to nine months, while building toward deeper structural change over the following two to three years. They did not wait for a complete future state platform to solve everything at once.

Design for Compliance, Not to Retrofit It

The most common mistake organizations make when modernizing AS/400 environments is treating compliance as something to address after the technical migration is complete. A migrated system is not automatically a compliant system. It becomes compliant only when the supporting controls, policies, and evidence mechanisms are built alongside the migration, not after it.

This means every modernization decision should be evaluated through a compliance lens from day one. The control framework that needs to be in place in the target state should be designed before the first workload moves.

The Controls That Cannot Wait Until After Migration

• Multi factor authentication for all privileged and standard user access
• Role based access controls tied to job function, not inherited from previous configurations
• Encryption in transit and at rest, applied at the data level, not only at the network perimeter
• Centralized logging with defined retention periods and immutability controls
• Automated monitoring and alerting, not periodic manual review
• Documented change management with evidence trails that survive audit scrutiny
• Incident response workflows that can be demonstrated, not just described
• Business associate agreement compliance where vendors or partners interact with PHI

Preserve Compliance During Migration, Not Just Before and After

Migration creates temporary blind spots. Data is moving, formats are converting, interfaces are changing, and parallel environments may run simultaneously. That is precisely when access, encryption, logging, and validation need to be most carefully maintained.

For HIPAA, data integrity and access history matter as much as data protection. If PHI moves between systems without full traceability, the migration itself becomes a gap that auditors will probe. For SOC 2, auditors will want to understand how the transition was controlled, and whether the evidence of controls was maintained or interrupted during the change period.

Practically, this means inventorying all workloads before moving anything, validating data format conversions including EBCDIC and packed decimals, running parallel environments long enough to confirm fidelity, and ensuring that no PHI moves without a documented and auditable trail.

Why Automation Is the Only Sustainable Path

If you modernize your AS/400 environment without also automating the compliance infrastructure around it, you have changed the technical landscape but not the compliance burden. Teams will still pull logs manually. Evidence will still be rebuilt separately for HIPAA and SOC 2. Access reviews will still be reconciled by hand. The cycle will still consume months.

This is where the difference becomes measurable. Teams that have centralized evidence collection and automated log aggregation have reduced audit preparation timelines by nearly 50%, bringing them down from close to a year to just four to five months. That shift does not come from modernization alone. It comes from automation.

Automation is not a feature of modernization. It is a condition that makes modernization sustainable. Without it, you have a better system doing the same manual compliance work.

The organizations that have achieved this reduction have treated automation as a first-class deliverable, not an enhancement to add later.

That means using it to continuously collect audit evidence rather than rebuilding it before each review, centralizing logs into searchable and tamper-evident repositories, automating access reviews rather than scheduling manual reconciliation cycles, and mapping the same control evidence across HIPAA and SOC 2 so the work is not duplicated.

It also means archiving dormant PHI into controlled repositories with enforced retention policies and audit logs, rather than leaving historical data in partially retired AS/400 partitions where it accumulates compliance risk quietly over time.

Where to Start: A Compliance First Assessment

The first step is not choosing a modernization path. The first step is understanding precisely what your AS/400 environment contains today and what compliance obligations are tied to it.

That means mapping every application, database, flat file, spool file, interface, user role, reporting job, and historical archive. It means identifying where PHI or sensitive operational data currently resides, who can access it, what logs exist and in what form, and what retention obligations apply.

Without that foundation, modernization becomes infrastructure work. With it, it becomes a structured programme for closing specific, demonstrable compliance gaps.

Five Questions Your Assessment Should Answer

1. Where does PHI or sensitive operational data currently reside across your AS/400 environment, including dormant partitions, legacy flat files, and archived exports?
2. Which controls are in place today, and which can be demonstrated clearly to an auditor versus which would require significant reconstruction?
3. Where are HIPAA and SOC 2 control gaps overlapping, and how much of the compliance preparation effort is currently being duplicated across frameworks?
4. Which workloads carry the highest compliance risk if left on AS/400, and which can be stabilized through archiving or controlled access enforcement without full migration?
5. What would your organization's audit preparation process look like if evidence collection were fully automated, and what is the gap between that and where you are today?

Conclusion

In most cases, you already know where the problem lies. The challenge is not identifying the gaps. It is addressing them without disrupting systems your business still depends on, while ensuring that what you put in place will hold up under audit scrutiny. That requires a clear plan.

If you are working toward HIPAA and SOC 2 readiness, the first step is to assess your AS/400 environment with that objective in mind. Identify where risk exists, what needs to be modernized, what should be archived, and how controls need to be strengthened so they can be consistently demonstrated.

If your next HIPAA or SOC 2 review is within the next 6 to 12 months and you have not mapped where PHI resides across your AS/400 environment, that is a gap that needs to be addressed now. The same applies if access logs cannot be produced on demand, or if audit evidence still depends on manual reconstruction. These are not theoretical risks. They are the exact points where audits slow down, escalate, or fail.

This is the stage where most teams realize that preparation alone is not enough. The environment needs to change.

Schedule a discussion with our team to evaluate your current setup, identify where compliance risk is concentrated, and define a modernization approach that aligns with both your audit timelines and operational constraints.