A certificate authority moved an internal archive from behind a VPN to a publicly accessible network zone in February 2025. Nobody reviewed the resulting attack surface. The exposure lasted more than a year, and the intrusion wasn't detected until June 2026. The archive held names, business emails, phone numbers, addresses, and in some cases passports, driver's licenses, and utility bills.
Your team probably isn't making the exact same mistake. But the beliefs that let it happen are common, and they sit comfortably inside organizations that hold current SOC 2 reports and ISO/IEC 27001 certificates. Here are five of them.
Myth 1: "A network change is operations work, not a security event"
Reality: Moving a system between network zones changes its risk profile as much as any code release does. Treating it as routine plumbing is how it skips review.
ISO/IEC 27001:2022 Annex A control 8.32 (Change management) requires that changes to information processing facilities and systems follow change management procedures. Clause 6.3 (Planning of changes) requires that changes to the ISMS be carried out in a planned manner. In SOC 2, the Common Criteria under CC8.1 cover authorizing, designing, testing, approving, and implementing changes to infrastructure.
In the DigiCert case, the move changed accessibility without a security review of the new attack surface. An account registration feature that was harmless behind a VPN became reachable by outsiders. That's the pattern: a feature's risk depends on who can reach it.
Myth 2: "Our system is only for storage, so authentication details don't matter much"
Reality: Assumptions about a system's purpose are not controls. Every capability that ships with the software has to be inventoried and assessed.
The archive was meant to store information, not create accounts. But the registration function existed, outsiders could use it, and accounts created that way weren't subject to multifactor authentication. Those accounts had read access only. Read access was enough to pull sensitive customer records.
Your risk assessment under clause 6.1.2 should evaluate what a system can do, not just what it's used for. Control 8.5 (Secure authentication) and SOC 2 CC6.1 both expect access paths to be deliberate. If your review process asks "what is this system for?" instead of "what can someone do with it from the new location?", you'll miss this class of flaw.
Myth 3: "Network segmentation is a one-time architecture decision"
Reality: Segmentation only works if it's maintained and if moving a system across a boundary triggers a formal decision.
Control 8.22 (Segregation of networks) requires groups of information services, users, and systems to be segregated. The control assumes the segregation holds over time. The DigiCert system was effectively resegmented from an internal zone to a public one by a single migration step.
Build this into your process:
- Define network zones and the data classifications each zone may host.
- Treat any zone change for a system holding confidential or personal data as a change requiring security sign-off.
- Block the change from proceeding if sign-off is missing, rather than relying on someone to remember.
Ask yourself: if an engineer moved a system holding identity documents into a public zone tomorrow, what would stop them? If the answer is "good judgment," that's a gap an assessor can reasonably call out.
Myth 4: "If something went wrong, our monitoring would have caught it"
Reality: Having monitoring is not the same as having monitoring that covers the conditions that matter. Here, exposure persisted for more than a year before detection.
Control 8.16 (Monitoring activities) requires networks, systems, and applications to be monitored for anomalous behavior, with appropriate action taken to evaluate potential incidents. SOC 2 CC7.2 sets a similar expectation. Both are about effectiveness, not the existence of a tool.
The details here are instructive. When the intrusion was first spotted, the initial conclusion was that the unauthorized account couldn't reach data because it wasn't assigned to any application. That conclusion was wrong. The actual attack path was identified a few days later, after a managed security program flagged the flaw. Afterward, the company added a SIEM alert for blocked access attempts, closing a monitoring gap that evidently existed before.
Two lessons follow. First, review your alerting for externally reachable systems, including alerts on new account creation and unusual read volume against sensitive stores. Second, test your triage assumptions. A rule like "an unassigned account can't touch data" should be verified, not asserted.
Myth 5: "Passing our audit means this kind of gap would have been found"
Reality: Audits sample. They test whether your controls are designed and operating, not whether every system is correctly configured today.
A SOC 2 Type II examination or an ISO/IEC 27001 surveillance audit evaluates the design and operation of your change management process through sampling and evidence review. If a migration bypasses that process entirely, the sample may never include it. The process looks sound on paper while a specific change slips through.
This is why you can't outsource assurance to the audit cycle. Your internal audit program under clause 9.2 should include targeted checks on changes that affect network exposure, not only a review of whether change tickets are filled out. Pull a list of network zone and firewall changes from the period, and trace each back to an approval and a security review. Any change that has no review record is a candidate Nonconformity, and you want to find it before your assessor does.
What to do instead
Fix the process, not just the incident.
- Make network exposure a defined change category. Any change that alters who can reach a system requires a documented security review before approval.
- Tie reviews to data classification. Systems holding identity documents or personal data get stricter gating, and zone changes for them need explicit sign-off.
- Inventory functions, not just assets. Review exposed features such as self-registration, default endpoints, and admin interfaces as part of every pre-migration checklist.
- Run a post-change verification. After a migration, scan from the new vantage point to confirm only the intended services are reachable.
- Tune monitoring to exposure. Alert on account creation, blocked access attempts, and anomalous reads for sensitive stores, and validate your triage logic periodically.
- Audit the exceptions. Use internal audit to hunt for changes that bypassed the process, then document findings in a Risk Treatment Plan.
A year of exposure came from one skipped step. Your job is to make sure that step can't be skipped quietly.
