On 11 November 2026 the Taiwan Stock Exchange (TWSE) sent listed companies the revised Cybersecurity Control Guidelines for Listed and OTC Companies (上市上櫃公司資通安全管控指引) together with a comparison table of amendments. The guidelines were first issued on 24 December 2021 and amended once, on 10 September 2024; this is the second revision[1]. It adds a new chapter on AI risk management, with 3 new articles (2 of them on AI) and 10 amended articles. TWSE says the aims are to strengthen risk management and security governance around listed companies' use of AI, and to align with the Regulations on Classification of Cyber Security Responsibility Levels as revised by the Ministry of Digital Affairs in 2026[1]. The guidelines grow from 41 to 44 articles, and every article from the former Article 16 onward has a new number[2].

This guide is for IT heads, CISOs and compliance staff at Taiwan listed and OTC companies, and for suppliers whose listed-company customers ask them to follow the guidelines. It covers the legal basis, who the guidelines apply to and the FSC's security staffing rules, then the old-to-new article mapping, the main points of each chapter, how the guidelines relate to other rules, and finally how to run a gap assessment against the new version. For implementation detail on each topic, follow the linked articles.

What the guidelines are: legal basis, scope and the binding rules around them

Legal basis: the security controls in a company's internal control system

Article 1 says the guidelines exist to help listed and OTC companies strengthen their security protection and management, and to meet the controls for computerized information systems required by Article 9 of the Regulations Governing Establishment of Internal Control Systems by Public Companies (公開發行公司建立內部控制制度處理準則)[3]. Article 9 of those regulations lists the controls a company using computerized information systems must at least include in its internal control system; item 10 is "control over information and communication security inspections". Article 13 also requires every annual audit plan to cover information and communication security inspection[4]. The FSC's Q&A on the regulations states that companies designing their security controls can refer to the guidelines[5]. In other words, the guidelines are not a law, but they are the reference baseline for the security controls in a company's internal control system, and an internal auditor checking information security will naturally compare against them.

Scope and "adopt as appropriate"

The guidelines' title and articles address listed and OTC companies[3]. TWSE's November letter went to all listed companies, with a copy to the Taipei Exchange (TPEx)[1]. Article 44 (formerly Article 41) says that, unless laws or TWSE and TPEx rules provide otherwise, companies may adopt the guidelines "as appropriate" to their industry, size and cyber risk[2], and TWSE's letter repeats this[1].

"As appropriate" does not mean the document can be ignored. At least three articles have binding rules behind them: Article 3 on a dedicated security head and staff corresponds to the FSC's staffing order (see the next subsection); Article 37 on major incidents corresponds to the material information disclosure procedures; and Article 42 on annual report disclosure corresponds to the Regulations Governing Information to be Published in Annual Reports of Public Companies (公開發行公司年報應行記載事項準則)[3][6]. For any other article you decide not to adopt, or to meet in a different way, write the reasoning into your risk assessment and have it approved by the responsible executive, so it can be explained in an audit.

CISO and dedicated security staff: the FSC's tiered rules

Article 3 of the guidelines only asks companies to "assign suitable personnel" as the dedicated security head and staff[3]; numbers and deadlines are set elsewhere. Article 9-1 of the internal control regulations requires public companies to allocate adequate staff and equipment to plan, monitor and carry out information security, and allows the FSC to order companies that meet certain conditions to appoint a chief information security officer and set up a dedicated information security unit with a head and staff[4]. On that basis the FSC issued order No. 11003656544 on 28 December 2021, effective 1 January 2022[7]:

  • Listed and OTC companies meeting any of these conditions: paid-in capital of NT$10 billion or more; a constituent of the Taiwan 50 Index at the end of the previous year; or revenue from selling goods or providing services online or through other electronic means of at least 80% of operating revenue in the latest year, or at least 50% over the latest two years combined. These companies had to appoint, by the end of 2022, the person who oversees security policy and resource allocation as CISO, and set up a dedicated security unit with a head and at least two dedicated staff.
  • Other listed and OTC companies with no consecutive pre-tax losses over the last three years and net worth per share in the latest financial statements not below par value had to appoint a dedicated security head and at least one dedicated staff member by the end of 2023.
  • Companies that meet the conditions later: those meeting the first set of conditions from 1 January 2023, or the second from 1 January 2024, must adjust their staffing within six months of meeting them.

The FSC's Q&A, in its 7 October 2024 version, adds[5]:

  • The CISO is typically a senior executive at vice-president level or above; when appointing one, consider whether the person's rank and authority are enough for the role.
  • Whoever handles information security is the dedicated security staff; the rules do not force companies to hire full-time staff, but companies should assess, based on the risks and needs they actually face, whether to assign full-time staff through additional hiring or a division of duties.
  • The internal control system should define the functions and duties of the dedicated security unit; if this requires changing the organization structure, the internal control system must be amended and approved by the board.

Companies meeting neither set of conditions are still bound by the general duty in Article 9-1 to allocate adequate staff and equipment[4]. For the CISO's role in disclosure decisions, see Security Incidents and Material Information Disclosure.

Why suppliers should read them too

The guidelines address listed companies, but several articles reach suppliers through contracts. Article 16 asks companies to identify the third-party software, services, libraries and other components their systems use, and says contracts should require suppliers to report security vulnerabilities proactively and provide fixes within a set time. Article 33 requires procurement documents to state the service level agreement (SLA), security requirements and the right to audit the vendor's security. Article 34 requires the company, when an outsourcing relationship ends, to confirm that the vendor has returned, handed over, deleted or destroyed the data it held under the contract. Article 41 calls for regular security audits of both the company and its outsourcing vendors[3]. When a customer sends you such clauses, map them to these articles first and ask exactly which item the customer wants and what evidence it expects.

What changed in November 2026

The comparison table is dated 9 November 2026 (ROC year 115)[2]. The new version has 11 chapters and 44 articles, up from 10 chapters and 41 articles[3][8]. The changes fall into three groups[2].

New articles

  • Article 16 (third-party components): identify the third-party software, services, libraries and other components used by information systems, and contracts should require suppliers to report security vulnerabilities proactively and provide patches or security updates within a set time. The explanatory note says it draws on the system and service acquisition, supply chain and vulnerability management requirements of the protection baseline in the classification regulations[2]. For supply-chain risk, see Supply Chain Attacks.
  • Article 38 (AI risk management): when an AI system or service involves core business or sensitive data, or can connect to, operate, change or trigger functions of information systems, companies should take five risk management measures in line with the nature of the business and the level of risk (see below)[2].
  • Article 39 (low-risk AI use): AI used only for low-risk support such as look-ups, summaries, translation, training and internal drafts, and not involving the uses in Article 38, can be handled under existing security management measures[2].

Amended articles (former number in brackets)

  • Article 9: backups must now include off-site backups for disaster recovery, and offline or immutable backups that ransomware cannot encrypt[2]. For backup design, see Backup Strategy: the 3-2-1 Rule and Immutable Copies.
  • Article 10: the "core business continuity plan" is renamed a "business continuity plan" (營運持續計畫); what the exercises must cover is unchanged[2].
  • Article 15: in addition to development and maintenance documents, system source code must also be stored and managed[2].
  • Article 17 (formerly 16): testing of core information systems grows from three items (vulnerability scanning, penetration testing, pre-launch source code scanning) to five: regular database security reviews are added, source code scanning becomes "before launch and regularly", and red teaming is to be assessed according to the company's risk. Internet-facing systems are also recommended to undergo suitable items chosen on the basis of a risk assessment[2]. For how these tests differ, see Vulnerability Scanning, Penetration Testing and Red Teaming.
  • Article 18 (formerly 17): beyond network segmentation, areas holding core systems or sensitive data should go further and use micro-segmentation to tighten isolation boundaries[2]. For the concept, see Zero Trust.
  • Article 19 (formerly 18): endpoint detection and response (EDR) is added to the required protections, making eight; "companies with mail servers" becomes "companies with email services" to reflect how email is now delivered[2]. For how EDR and a SOC differ, see EDR, XDR, SIEM, SOC and MDR.
  • Article 22 (formerly 21): the old term for password (通行碼) becomes the current one (密碼), a forced change at first sign-in is added, and "multiple authentication technologies" becomes "a zero trust architecture such as multi-factor authentication"[2]. For implementation, see Password Policy and Password Managers.
  • Article 25 (formerly 24): the term for MFA in remote access is changed to match the wording of the classification regulations[2].
  • Article 34 (formerly 33): wording tightened; the table says there is no substantive change[2].
  • Article 35 (formerly 34): in addition to incident response and reporting procedures, companies must now "regularly hold response exercises to verify their effectiveness"[2]. For how to run one, see Running a Cyber Tabletop Exercise.

Renumbered only, content unchanged

Former Articles 19–20 become 20–21, 22–23 become 23–24, 25–30 become 26–31, 31–32 become 32–33, 35–36 become 36–37, and 37–41 become 40–44[2]. Articles 1–8 and 11–14 are not in the table; their numbers and content are unchanged[2]. If internal policies, the internal control system or audit plans cite article numbers, update them.

As of 14 November 2026, the TWSE regulations database still shows the 10-chapter, 41-article version amended on 10 September 2024[8]. The new text and comparison table are attachments to TWSE's letter and are also posted in the cybersecurity section of TWSE's domestic outreach website, with an update date of 11 November 2026[1][9]. The letter does not mention an effective date or transition period[1].

Chapter by chapter: which articles need evidence first

The summary below follows the chapters of the new version and highlights the articles with a clear frequency or output, which are the easiest to check against documents.

Policy and organization (Chapters 1–2, Articles 1–6)

Article 2 defines "information and communication system" and "information and communication service" in the same words as Article 3 of the Cyber Security Management Act, and also defines core business, core information systems and sensitive data[3][10]. Articles 3 to 6 require a security steering organization with an assigned dedicated security head and staff; a security policy and objectives approved by a vice president or above and reviewed regularly; security procedures covering the topics of each chapter; and annual security awareness training for everyone who uses information systems, plus annual professional training for security managers and staff[3]. Evidence to have ready: organization and responsibilities, policy approval records, and annual training rosters and hours.

Core business, inventory and risk assessment (Chapters 3–4, Articles 7–12)

Companies must identify their core business, the sensitive data to protect, and the legal and contractual requirements that apply; set recovery time objectives (RTO) and recovery point objectives (RPO) for core business, with backups and redundancy; draw up a business continuity plan and exercise it regularly; inventory information systems regularly and keep an information asset register for core systems; and carry out regular security risk assessments[3]. For how to build the register, see Asset Inventory and External Attack Surface Management. These articles underpin the rest: the mandatory testing scope in Article 17 is core information systems, and the AI threshold in Article 38 is likewise defined by core business and sensitive data[3].

System development and maintenance (Chapter 5, Articles 13–17)

Put security requirements into development and maintenance specifications, test them regularly, store documents and source code properly, identify third-party components, and test core information systems and fix the vulnerabilities found[3]. Of the five tests in Article 17, vulnerability scanning, penetration testing, database security reviews and source code scanning are all "regular", while red teaming is to be "assessed according to the company's risk"[3]. The guidelines do not set frequencies, so companies must set their own and write them into procedures. For common application weaknesses, see OWASP Top 10.

Protection and controls (Chapter 6, Articles 18–31)

This is the longest chapter, with 14 articles[3]. The articles with the most concrete items or frequencies, and so the easiest to check one by one, are:

  • Article 19, eight protections: antivirus, network firewall, email filtering (for companies with email services), intrusion detection and prevention, a web application firewall (for companies with internet-facing core systems), advanced persistent threat defenses, EDR, and a security threat detection and management capability (SOC)[3].
  • Articles 22 and 23, passwords and accounts: password management rules, plus regular review of privileged accounts, user accounts and permissions, with long-unused accounts disabled[3]. For the order in which to roll out MFA, see MFA Rollout Guide.
  • Article 24, monitoring and logs: examples include failed sign-ins, sign-ins outside working hours and successful sign-ins by several users from the same source IP, and logs must be protected[3]. For retention, see What to Log and How Long to Keep It.
  • Article 25, remote access: secure connection methods such as VPN and VDI, plus multi-factor authentication, encrypted connections, least privilege, a complete audit trail of user actions, monitoring of abnormal behavior and vulnerability updates[3]. For the devices themselves, see Hardening Checklist for Edge Devices.
  • Article 28, patching: watch vulnerability notices, patch high-risk vulnerabilities promptly, and regularly assess patching of devices, system components, database systems and software[3]. For prioritization, see Patch Management.
  • Article 31, social engineering drills: run an email social engineering drill every year, train staff who opened the emails or links, and keep records[3]. For design and metrics, see Social Engineering Drills That Work.

The remaining articles cover protection of sensitive data, onboarding and offboarding with confidentiality agreements, management of signage and digital displays in public venues, computer room management, equipment reuse and disposal, and rules on staff use of devices[3].

Outsourcing and incident response (Chapters 7–8, Articles 32–37)

For the three outsourcing articles, see "Why suppliers should read them too" above. On incident response, Article 35 requires response and reporting procedures that cover impact and damage assessment, internal and external reporting flows, how to notify other affected organizations, and contact points; companies may refer to TWCERT/CC's incident response guide for enterprises, and must exercise the procedures regularly. Article 36 asks companies to join threat intelligence sharing bodies such as their industry ISAC or TWCERT/CC[3]. TWSE's letter also encourages listed companies to become TWCERT/CC members, which is free[1]. For what to do in the first hours of an incident, see The First 24 Hours of a Suspected Breach.

AI risk management (Chapter 9, Articles 38–39)

The five measures in Article 38[3]:

  1. Consider adopting the Ministry of Digital Affairs' AI risk classification framework, or AI guidance issued by the industry's competent authority.
  2. Companies should set security rules for staff use of AI systems and services, and manage unauthorized use.
  3. When introducing, developing or significantly changing an AI system, carry out security assessment or testing in proportion to risk, review how the model is performing regularly, and manage supply-chain risk for AI models and third-party components.
  4. For agentic AI that can plan steps, call tools and access data across systems to advance a task, limit its purposes, data, tools, destinations and execution permissions; for automated actions with a major or irreversible impact on core business, sensitive data or information systems, put human approval, guardrails or other controls in place.
  5. Set up monitoring and logging in proportion to risk, so that important actions, behavioral drift and anomalies can be traced.

The references listed in the comparison table include the Ministry of Digital Affairs' AI risk classification framework, the FSC's AI guidelines for the financial sector and its security advisory on agentic AI in finance, the Industrial Development Administration's AI adoption guide for manufacturing, ISO/IEC 42001:2023, NIST AI RMF 1.0 and its Generative AI Profile (NIST AI 600-1), and COSO's guidance on internal control over generative AI[2]. The key is the threshold in Article 38: an employee using AI to translate a public text is a low-risk use under Article 39; pasting in customer data containing personal data, or letting an AI agent call internal system APIs, falls under Article 38. For data leakage, prompt injection and other generative AI risks, see Generative AI Security.

Continuous improvement and supplementary provisions (Chapters 10–11, Articles 40–44)

The security steering organization reports regularly to the board or management; the company audits itself and its outsourcing vendors regularly and follows up on findings; discloses security information in the annual report; evaluates third-party certification; and Article 44 provides for adoption as appropriate[3].

How the guidelines relate to disclosure, annual reports, ISO 27001/SOC 2 and the Cyber Security Management Act

  • Material information disclosure: Article 37 only says that a major security incident meeting the material information procedures "shall be handled under the relevant rules"[3]. The tests, deadlines and required content are in the TWSE and TPEx material information procedures; see Security Incidents and Material Information Disclosure.
  • Annual reports: Article 42 asks companies to describe in the annual report their security policy, specific management programs, resources invested, and the losses, possible impact and response to major security incidents[3]. This is already required by Article 18 of the annual report regulations: companies must describe their security risk management framework, security policy, specific management programs and resources invested, and list the losses, possible impact and response measures from major security incidents in the latest year and up to the printing date, explaining why if the amounts cannot be reasonably estimated[6]. The risk section under Article 20 of the same regulations also requires an analysis of how technological change (including information security risk) affects the company's finances and business, and the response[6].
  • ISO 27001 and SOC 2: Article 43 asks companies to evaluate adopting ISO 27001, CNS 27001 or another information security management system standard of equal or greater effect, obtaining third-party certification and keeping it valid, or to evaluate obtaining an AICPA SOC 2 Type 2[3]. The wording is "evaluate"; it does not require certification, but keep a record of the evaluation and its conclusion. For what each one is and how to choose, see ISO/IEC 27001:2022 and CNS 27001 and SOC 2, ISO 27001 and Security Questionnaires.
  • Cyber Security Management Act: the Act covers government agencies and specific non-government agencies, meaning critical infrastructure providers, state-owned enterprises, specified foundations, and government-controlled enterprises, groups or institutions[10]. Most listed companies are none of these and are not directly bound by the Act; but a company that is a specific non-government agency (for example, one designated as a critical infrastructure provider) must comply with both the Act and the guidelines. Several of the amendments cite, in their explanatory notes, the required measures and protection baseline of the Regulations on Classification of Cyber Security Responsibility Levels, last amended on 7 January 2026[2][11], so companies that already built controls to those regulations will find the gap smaller. For the Act's obligations, see Taiwan's Cyber Security Management Act.
  • Personal data protection: the guidelines give personal data as an example of sensitive data[3]; for breach notification duties under the Personal Data Protection Act, see PDPA Key Points.

Running a gap assessment against the new version

  1. Build a checklist of all 44 articles: for each, record the new and old numbers, whether you adopt it and why (by industry, size and cyber risk under Article 44), current status, evidence, owner and target date.
  2. Start with the 13 changed articles: new Articles 16, 38 and 39, and amended Articles 9, 10, 15, 17, 18, 19, 22, 25, 34 and 35[2]. Articles 10, 25 and 34 are mainly wording changes and usually need only document updates.
  3. Inventory AI use: list the AI services in use, in-house models and AI agents, and flag those that involve core business or sensitive data, or can connect to or operate information systems. These fall under Article 38; bring the rest under existing controls per Article 39[3].
  4. Fill in the third-party component list and contract clauses: for systems developed in-house or by vendors, list the open-source and commercial components used; add clauses on proactive vulnerability reporting and patch deadlines to outsourcing and procurement contracts[3].
  5. Check backups and the testing plan: confirm core business has off-site backups and offline or immutable backups; add database security reviews and regular source code scanning to the testing plan, and write down the conclusion of the red-team assessment[3].
  6. Schedule response exercises: the Article 35 response exercise can be planned together with the Article 10 business continuity exercise, but the records should show which procedure each part tested.
  7. Update internal controls and the audit plan: revise internal documents that cite old article numbers, feed the gap assessment results into the security inspection item of the annual audit plan[4], and report to the board or management under Article 40[3].

Action checklist

  • Download the new guidelines and comparison table, and make sure nothing internal still cites the 2024 version shown in the regulations database.
  • Confirm which FSC staffing tier applies to your company, and check the appointment records for the CISO, the dedicated security head and dedicated staff.
  • Run a gap assessment against all 44 articles; for any article you don't adopt or meet differently, record the reason and have it approved by the responsible executive.
  • Inventory AI services and agents, set rules for staff use, and give agents that can operate systems permission limits, human approval and logging.
  • Build a third-party component list and update outsourcing and procurement contracts with vulnerability reporting, patch deadlines and audit rights.
  • Put off-site and offline (or immutable) backups in place, and update testing items and frequencies.
  • Schedule this year's email social engineering drill and incident response exercise, and keep records.
  • Check that annual report security disclosures and the material information decision process line up with Articles 37 and 42.
  • Evaluate whether you need ISO 27001/CNS 27001 certification or a SOC 2 Type 2, and write the conclusion down.
  • If you lack the in-house capacity for a first gap assessment, consider a security health check; subscribe to keep up with rule changes and vulnerabilities.