Cybersecurity Duties Do Not End at Go-Live: Three Enforcement Cases and the Operational Gaps Behind Them

Primary keyword: cybersecurity protection obligations Secondary keywords: cybersecurity compliance, data security management, network security classification, test environment security

One oversight can turn a data-handling weakness into an incident

Cybersecurity problems do not always begin with a sophisticated attack. The risk may sit in an unprotected office computer, an unattended visitor-registration application, or a test server that remains reachable from the internet after the work is done. Three enforcement cases recently disclosed by China’s public-security cybersecurity authorities involve a medical institution, a company’s visitor-registration system, and a telephony system’s test server. Together, they make a practical point: calling a system “non-core” or “test” does not, by itself, remove the operator’s security responsibilities.

According to the published case notice, a medical institution in Zhangzhou, Fujian, had poorly controlled system permissions that allowed cross-role operations. Some staff exported more than 1,800 records and stored them on internet-connected computers without effective security protection. A company in Longyan, Fujian, operated a visitor-registration system containing visitor information but had not implemented adequate data-security measures. In a third case, a company in Quanzhou, Fujian, failed to take the telephony test system offline after testing. The server was compromised and its outbound-calling function was abused. The first two cases were handled under the Data Security Law; the third under the Cybersecurity Law. The authorities ordered corrective action and imposed administrative penalties.

These cases are not a universal penalty schedule or a substitute for legal advice. They do, however, offer useful questions for executives and IT leaders: who can use each system, where does data travel, which internet-facing assets remain active, and can the organization detect and contain abnormal activity in time?

Enterprise cybersecurity governance across data boundaries, system ownership, and test-system retirement

Security obligations apply to operations, not just policy documents

China’s Cybersecurity Law requires network operators to fulfill security-protection obligations under the multi-level cybersecurity protection framework. These duties include establishing internal security rules and operating procedures, appointing a cybersecurity lead, deploying technical measures against attacks and intrusions, monitoring and recording network operations and incidents, and applying measures such as data classification, backup, and encryption for important data. A policy document or a one-time assessment cannot, on its own, demonstrate that controls are working. The practical questions are whether controls operate continuously, whether activity can be traced, and whether responsibility is assigned to specific roles.

The Data Security Law adds obligations for organizations conducting data-processing activities: establish end-to-end data-security management, provide training, and take necessary technical and organizational measures. Risks and vulnerabilities require timely remediation; a data-security incident must be handled promptly and reported as required. The two legal frameworks overlap, but they are not interchangeable. Cybersecurity duties address network operation and protection, while data-security duties apply across activities such as collection, storage, use, processing, transmission, provision, and disclosure. Organizations should assess the system, data, and applicable rules together rather than treating a completed classification-protection assessment as proof that every duty has been met.

Legislation and article numbering may change. Readers should consult the official, currently effective text before taking legal or remediation decisions. This article offers general technical and management guidance, not a legal opinion.

Case 1: Weak permissions and uncontrolled exports move sensitive data outside the managed boundary

Medical information systems may handle records, diagnoses, test results, prescriptions, and care notes. The disclosed case was not merely about a data export: it involved both permissions that did not adequately reflect job responsibilities and exported records being placed on computers without effective security protection. A single weak link can move data from a controlled system into an endpoint that is harder to govern and audit.

Organizations can review the data-access chain through several controls:

Grant access by role and responsibility. Map job duties to system roles and data scope. Avoid shared high-privilege accounts, and update or revoke access promptly when employees change roles or leave.
Put boundaries around exports. Permit exports only when operationally necessary. Require approval, masking or encryption as appropriate, and retain records of the requester, scope, time, destination, and purpose.
Control endpoint destinations. Identify which devices can access sensitive data. Apply endpoint protection, disk encryption, peripheral controls, and data-loss prevention where appropriate. Define how temporary files are reviewed and removed.
Review continuously. Reassess privileged, dormant, and unusual-time accounts. Check whether bulk queries and large exports match the user’s role and business need.

A control is effective when the system enforces access boundaries, logs support an investigation, and exceptions can be detected—not merely when employees have signed an acknowledgement.

Sensitive-data control flow: least privilege, approved export, managed endpoint, and audit trail

Case 2: A “peripheral” application can still be a personal-information entry point

Visitor registration, attendance, and meeting-room booking are often treated as auxiliary tools. They can therefore fall outside asset inventories, patch routines, and security reviews. But a system that collects or processes personal information still needs an accountable business owner, a defined data scope and retention period, access controls, and appropriate safeguards. A small system is not automatically low-risk; a non-core system should not be left ownerless.

Maintain a central inventory for every system and record at least its business owner, technical maintainer, hosting location, internet exposure, data types, account privileges, patch status, log location, backup and recovery method, and retirement conditions. Include both internally built systems and SaaS services. For vendor-operated systems, clarify data-processing boundaries, access methods, incident notification, vulnerability remediation, and data handling when the contract ends.

Controls can be proportionate to risk, but basic expectations should remain clear: no default passwords, no publicly exposed administrative console without appropriate protection, timely security updates, necessary access control and logging, and a named owner with a review schedule. When a system is no longer needed, complete data migration or deletion, revoke accounts, and remove obsolete DNS records and internet entry points. Merely stopping routine use is not decommissioning.

Case 3: Test-system retirement is part of production security

The telephony case shows why a test is not over just because the testing activity has ended. The server remained reachable from the internet and retained an outbound-calling capability. After attackers gained control, a feature intended for testing became a means to affect others. A test environment connected to production networks, holding real credentials, or able to call real business functions may present risks close to those of production.

IT teams can incorporate test environments into change management and asset lifecycle controls:

Define scope before deployment. Record the owner, purpose, exposed ports, allowed sources, test data, and end date. Prefer synthetic or masked data over direct copies of production data.
Apply a secure baseline. Patch the system, remove default accounts and unnecessary services, restrict management access and source addresses, and enforce clear separation from production networks.
Keep an audit trail during testing. Retain records of administrative actions, remote access, configuration changes, and sensitive business-function calls. Add alerts for abnormal traffic or high-risk behavior where appropriate.
Close and verify at the end. Follow a checklist to remove public access, release temporary credentials, revoke firewall exceptions, recover accounts, clean up data, and confirm that the service is no longer reachable. Have both the requester and system owner confirm closure.
Find forgotten assets continuously. Reconcile cloud inventories, domains and certificates, and external exposure scans to identify unowned hosts, test sites, and expired services.

Test-environment lifecycle: scope, baseline, monitoring, verified shutdown, and asset discovery

Turn legal duties into evidence that can be checked

When an organization needs to demonstrate that safeguards are in place, verbal assurances are rarely enough. Map each key obligation to four evidence areas: an accountable owner, a technical control, an operating record, and an incident-handling path.

Management objective	Verifiable control	Evidence to retain
Clear ownership and access	Role-based permissions, approvals, offboarding	Access matrix, approval records, review records
Defense against attacks and unauthorized access	Patching, boundary controls, endpoint protection, authentication	Baselines, remediation records, policy-change logs
Detection and investigation	Login and activity logs, alerts, audit	Retention settings, alert tickets, investigation records
Data confidentiality and availability	Classification, backup, encryption, recovery testing	Data inventory, backup reports, restore-test records
Timely incident response	Response plan, escalation and reporting process	Exercise records, incident timeline, remediation and review
Retirement of test systems	Expiry reminders, shutdown verification, asset reconciliation	Test request, expiry list, closure confirmation

The measures in the table are practical governance recommendations. Their scope should reflect applicable laws, sector requirements, system importance, and actual risk. Requirements such as log-retention periods, data classification, and incident reporting should be confirmed against current laws, regulator guidance, and applicable standards rather than set from a generic checklist alone.

Four questions for management to ask

First, does the organization know every system that is operating, serving users, or still reachable from the internet? Second, what personal, business, or important data does each system handle, and who authorizes access and export? Third, are there test assets that remain online, unmaintained, or capable of invoking real business functions? Fourth, if an anomaly occurs, can the team locate it, contain it, preserve evidence, and report it as required—with logs, contacts, and response procedures ready?

If the answers are unclear, the first priority is not another policy document. It is a reliable asset inventory, named ownership, and operational controls that can be verified, followed by remediation prioritized by risk. Cybersecurity protection obligations are reflected in daily configuration, approval, monitoring, maintenance, and review.

How DELine can help

DELine can work with an organization’s existing systems and operating processes to review its network and data-security posture, assess internet exposure and test environments, improve endpoint and access controls, support technical remediation related to the multi-level cybersecurity protection framework, and strengthen logging, monitoring, and incident-response processes. We recommend starting with a clear view of assets and risks, then building a practical plan with accountable owners, verifiable controls, and tracked remediation.

To discuss enterprise cybersecurity and ongoing operations, visit DELine or contact our team.

This article provides general technical and management information and does not constitute legal advice. For obligations, penalties, or remediation in a specific case, consult qualified counsel or the relevant authority based on the organization’s circumstances and the currently effective rules.