What Is a Security Health Check: What It Covers, How Often, and How to Read the Report

How the regulation defines it, and how it differs from other testing

Required items and frequency

The Regulations Governing the Classification of Cyber Security Responsibility Levels require each agency to carry out the items in Annexes 1 to 8 according to its responsibility level, and the security health check (health check below) is one of the technical items; the current annexes were amended and promulgated on 7 January 2026 and took effect on promulgation^[1]. The health check consists of these reviews^[1]:

• Network architecture review
• Network malicious activity review
• Client endpoint malicious activity review
• Server malicious activity review
• Directory service and firewall connection configuration review
• Database security review of core information systems (levels A and B only)

Frequency is the same for government agencies and specific non-government agencies at the same level: once a year at level A, once every two years at levels B and C, and not required at levels D and E; it starts from the year after initial approval, a change of level or a change to core information systems^[1]. Specific non-government agencies may instead use other measures of equal or greater effect approved by the central competent authority for their sector, while government agencies need approval from the competent authority^[1].

Note that the annexes list only the names of the items and their frequency; they do not prescribe methods, sample sizes or report formats^[1]. How deep the work goes depends on the procurement specification and the scope both sides agree; if the specification only says "health check as required by the Act", different vendors can deliver very different results. For who the Act covers and their other obligations, see Taiwan's Cyber Security Management Act.

The 2026 amendment: a new database security review

Two changes in the 2026 amendment affect the health check directly. First, levels A and B gained the "database security review of core information systems"; the explanatory notes say agencies should regularly review protection of database connections and logins, so that weak security settings do not expose internal information to improper disclosure, tampering or theft^[2]. Second, the former wording "directory server configuration" became "directory service configuration", which the explanatory notes for level C describe as harmonizing terminology^[2]. For agencies already approved, the deadline for items added or changed by this amendment runs from the date the amendment took effect^[1].

How it differs from vulnerability scanning, penetration testing and ISO 27001 audits

In the annexes, vulnerability scanning and penetration testing are listed under "security testing", separately from the health check^[1], so neither can stand in for the other. Each answers a different question:

• Vulnerability scan: which known vulnerabilities and misconfigurations do the listed hosts have.
• Penetration test: can a specified system actually be broken into.
• ISO 27001 certification audit: does the management system conform to the standard, and is it followed in practice.
• Health check: are there signs of existing compromise anywhere in the environment, and do the architecture and configuration leave easy paths for an attacker.

For scanning and penetration testing in detail, see Vulnerability Scanning, Penetration Testing and Red Teaming; for certification audits, see ISO/IEC 27001:2022 and CNS 27001. What sets the health check apart is the malicious activity review: a scanner reports CVEs and a penetration test proves a way in, but neither tells you whether an attacker is already inside. Conversely, a health check does not test a single application's access control or injection flaws in depth; that is the penetration test's job.

Level A and B agencies must also run a security monitoring mechanism and endpoint detection and response^[1]. For them the health check also serves as an outside check on monitoring: if the health check finds malicious connections or suspicious programs that the monitoring center never alerted on, there is a gap in detection rules or log sources.

What each item actually looks at, and common findings

The regulation does not define the details, but a 2025 government cyber security roadshow presentation on the website of the Administration for Cyber Security (ACS) lists the usual sub-items of a health check service^[3]. The sections below follow it, alongside findings from the 2025 technical inspections carried out during cyber security audits of government agencies, as compiled by the National Institute of Cyber Security (NICS)^[4]. An audit technical inspection is not a health check, but its network architecture, network malicious activity, domain controller and database items overlap with the health check, so it is a useful guide to what such reviews actually find.

Network architecture review

The sub-items are host placement, network zone layout and the design logic of the network architecture^[3]: whether servers, user computers, device management interfaces and public-facing services sit in separate segments, and whether traffic between segments is controlled. Common network architecture findings in the 2025 inspections included management interfaces on firewalls, switches and load balancers that were not restricted to specific source addresses, so anyone inside could reach them, and core network devices without physical redundancy, creating single points of failure^[4].

Network malicious activity review

The presentation lists this item as "wired network malicious activity review", with packet capture and analysis and network device log analysis as its sub-items^[3]: capturing traffic for a period and examining network device logs to find connections to command-and-control (C2) servers or unusual outbound transfers. In the audit technical inspections, for example, inspectors used the malicious C2 list that NICS publishes daily to test whether connections were blocked from both the user segment and the system administrator segment, and asked the agency for a live capture of complete traffic to run NICS's own APT traffic detection rules against^[3]. The 2025 inspections found 304 C2 domain names that were not blocked, while all C2 IP addresses were^[4]; NICS noted that agencies had not confirmed their C2 blocklists were deployed completely and correctly^[4]. The longer and more complete your logs, the further back this review can look; for planning retention, see logging and retention.

Client endpoint and server malicious activity review

The sub-items are a review for malware or malicious files and a review of updates^[3]. When accepting the work, check that the vendor looked beyond antivirus results at suspicious persistence (scheduled tasks, services, startup items), unknown local administrator accounts and missing patches. In the 2025 inspections, none of the user computers tested had malware and all had current antivirus signatures, but 14 had not applied operating system security updates and 2 had not updated applications^[4]. "No malware found" only means the hosts and methods used this time found none, so the report should state which hosts were checked and how.

Directory service and firewall connection configuration review

For the directory service, the sub-item is a review of AD settings against the Government Configuration Baseline (GCB); for firewalls, a review of connection settings^[3]. The 2025 inspections found firewall rules allowing internal hosts outbound connections to any destination and service, and rules containing "Permit All" or "Permit Any"^[4]; when a compromised host tries to send data out or call back to a C2 server, such rules stop nothing. On the cloud directory side, the 2025 inspections also trialled (without scoring) a review of Microsoft Entra ID against CISA's SCuBA secure configuration baselines and found that "allow user consent for apps" did not meet CISA's recommendation, which could let users authorize third-party apps on their own and lead to data leaks^[4]. The same presentation also lists GCB settings reviews for operating systems, browsers, network devices and applications among the health check service items^[3].

Core information system database security review

This item was added in 2026 and applies to levels A and B only. The presentation lists its sub-items as privileged account management, data encryption, access authorization, audit logs, outsourcing management, backup protection and vulnerability management^[3]. In the 2025 inspections, the database nonconformity was that connections, although encrypted, still supported TLS 1.0 and TLS 1.1, which have known weaknesses^[4].

Preparation: scope, access and data handling

Checklist

• Asset inventory and network diagrams: include branch sites, cloud environments, VPNs and public-facing services. If the diagram is badly out of date, that is the first finding.
• Scope and sampling: which segments to capture, how many computers and servers to examine, and which systems count as core information systems (levels A and B need the database review). Write all of this into the specification, because the regulation does not decide it for you.
• Access and equipment: read-only accounts on firewalls and domain controllers, a switch mirror port (SPAN) or TAP for packet capture, and permission to run collection tools on endpoints. Use dedicated accounts and disable them the day the work ends.
• Timing: capture across normal working days so the traffic is representative; avoid go-lives and year-end freezes, and leave time before the deadline for fixes and a re-check.

Assessors will see sensitive data

NIST SP 800-115 notes that assessors may need access to sensitive information about network architecture, security posture and weaknesses, and that some organizations therefore require background checks^[5]. Captured packets may contain employees' personal data or data that does not belong to the organization, so the legal team should address privacy before the work begins, and may require outside assessors to sign a nondisclosure agreement^[5]. The assessment plan should set out data handling: storage of data on the assessors' systems during the work (physical security, passwords and encryption), storage after the work ends, transmission over internal or external networks, and removal from systems at the end; some organizations bar third parties from keeping any assessment data after the final report and have a qualified person from the organization verify that it was sanitized^[5].

When agencies covered by the Act outsource work, Article 7 of the Enforcement Rules of the Cyber Security Management Act requires attention to, among other things: the contractor must immediately notify the agency of any security incident it becomes aware of and the remedial measures taken; and when the contract ends or is terminated, the agency must confirm the contractor has returned, handed over, deleted or destroyed the data it held to perform the contract^[6]. If the health check will touch personal data, Article 8 of the Enforcement Rules of the Personal Data Protection Act lists what to supervise when entrusting personal data to others, including return of the data media and deletion of data the contractor stored when the engagement ends, with regular checks on the contractor that are recorded^[7].

Agree in advance: what happens if they find an intruder

SP 800-115 recommends that the assessment plan define what counts as an incident and state what assessors should do if they discover an actual intruder or an intruder's footprints: whether testing stops, when it can resume and on whose authority, and primary and alternate contacts on both sides^[5]. Put this into the contract, together with how quickly you must be notified and who preserves the evidence.

Reading the report: separate "already compromised" from "needs improvement"

Signs of compromise: handle as a security incident

Confirmed malware, traffic to known C2 servers, unknown administrator accounts or web shells are not items for the improvement list; they are security incidents. Start incident response: preserve evidence and establish scope first, and do not simply reimage and move on; see The first 24 hours after a suspected intrusion for the steps. Agencies covered by the Act must report a security incident within one hour of becoming aware of it (Article 6 for government agencies, Article 11 for specific non-government agencies)^[8], so decide in advance who, when the health check vendor reports suspicious signs, judges straight away whether it is a security incident and starts the report.

Improvement findings: rank by exposure and exploitability

Rank the remaining findings by "can it be reached from outside", "is there a known way to exploit it" and "does it affect a key control point such as AD or the firewall", rather than relying only on the report's high, medium and low labels. For a ranking method, see Patch management: how to prioritize when you cannot fix everything. Read findings together, too: unrestricted outbound rules plus an incomplete C2 blocklist mean that once a host is compromised, almost nothing stops data from leaving.

Assign owners and deadlines, then re-check

Every finding needs an owner and a deadline, and a re-check once it is fixed. Compare with the previous report as well: several of the common findings NICS compiled for 2025 were the same as in 2024^[4]. Repeat findings usually point to a process problem, such as firewall rules without change management or periodic review; fix only the individual setting and the next health check will find it again.

When accepting the report, check that it states scope and sampling (which segments were captured and for how long, which hosts were examined), the methods and tools used, evidence for each finding, and whether signs of compromise are listed separately from improvement items.

Companies not covered by the Act: start yourself, bring in outside help when needed

For private companies the Act does not cover, the questions a health check answers still apply: is there an attacker in the environment, and which settings make an attacker's job easy.

Start with the ACS self-assessment checklist

In March 2026 the ACS published the Basic Cyber Security Protection Guidelines for SMEs with a self-assessment checklist of 16 items across three areas, account management, device and data management, and security awareness training, such as passwords of at least 15 characters, an inventory of all devices, and 3-2-1 backups with regular restore drills^[9]. The checklist tests whether basic protections are in place; it will not tell you whether an attacker is already in your environment.

A lightweight self-run health check

Following the statutory items, an internal team can start with:

• Network architecture: update the diagram and check whether user segments can reach servers and device management interfaces directly.
• Network malicious activity: match indicators of compromise from advisories against DNS and firewall logs; see How to check your environment against IOCs in advisories.
• Endpoints and servers: use the antivirus or EDR console to find computers with no agent, no check-in or stale signatures, and list missing patches and unsupported systems; on servers, look for scheduled tasks, services and local administrator accounts you do not recognize.
• Directory service: list members of Domain Admins and other privileged groups, and accounts that are still enabled but have not signed in for a long time; in the cloud directory, check whether users can consent to third-party apps themselves.
• Firewall and database: find outbound rules that allow any destination, Any rules and rules without an owner; check who can connect to databases and whether old TLS versions are still allowed.

When an outside health check is worth it

• No one in-house can interpret packet captures and endpoint findings.
• A customer, parent company or regulator requires a third-party report.
• After a merger, a data center move or a major network change.
• A peer has been breached, you have received an advisory, or there are suspicious signs you cannot confirm internally.
• The people checking are the people who configured it, so blind spots are inevitable.

The ACS has also arranged for NICS to fund university security faculty to run practical courses, after which trained students form "security health check teams" that visit SMEs on site and recommend improvements^[10]. When you need a full outside health check, see our security health check service.

Action checklist

• Confirm your responsibility level, health check frequency and next due date; at levels A and B, add the database security review introduced in 2026 to the specification.
• In the specification, set out the method for each item, the segments and duration for packet capture, the number of endpoints and servers sampled, the deliverables and a re-check.
• Before work starts, prepare the asset inventory, network diagrams, read-only accounts and capture points, and sign the NDA and clauses on data storage, transmission and deletion.
• Agree in advance on contacts, notification time and whether work pauses if signs of intrusion are found, and name who decides whether it is a security incident.
• Split the report into "signs of compromise" and "needs improvement": start incident response immediately for the first, and rank the second by exposure and exploitability.
• Give every finding an owner and a deadline, re-check after fixes, and compare with the previous report for repeat findings.
• If the Act does not cover you, start with the ACS self-assessment checklist and the lightweight self-run check, then decide whether to bring in an outside team.
• Follow the latest indicators of compromise in advisories as a matching source for day-to-day network malicious activity review.