Delivery and Maintenance Evidence for Public-Sector Projects in Taiwan

Acceptance on a public-sector project is checked against the documents, quantities, and formats that the contract and the tender requirements list item by item. Maintenance follows the same logic: the agency wants evidence it can look up, and a verbal assurance is not an acceptance item.

A development team has three things it can do under that logic: read the requirements into a checklist before quoting, let routine checks generate the evidence files automatically during maintenance, and put both what was found and what could not be found into the incident report. For the types of security testing and how the work is divided, start with the difference between vulnerability scanning and penetration testing. POLISH is a development and maintenance team, and this article covers the delivery and maintenance work before and after testing.

Acceptance follows the document names and quantities in the requirements

Under the Government Procurement Act, Chapter 4 governs performance management and Chapter 5 governs acceptance and payment; these chapters together are the legal basis for how agencies and vendors perform, accept, and pay (Government Procurement Act, 2019). The time allowed for completing acceptance and correcting non-conforming items is set by the contract and the current text of the Act.

The Enforcement Rules of the Government Procurement Act go further in Chapter 5, which details the acceptance procedure: when paper-based acceptance applies, completion notices and joint inspection, preliminary and final acceptance, acceptance records, and, for projects that reach the publicly announced amount, a settlement acceptance certificate (Enforcement Rules of the Government Procurement Act, 2021). The Rules and the Act sit at different levels of law, so confirm the current version of each separately.

All of these procedures end up on one checklist: which documents the requirements list, how many of each, and in what format. Entries can be as fine as quantity, unit, and format, for example “one set of architecture diagrams, PDF” or “one video, MP4.” Acceptance compares delivery against that exact wording.

There is also a trap in the other direction. Building a working system does not cancel a document obligation. Before quoting, confirm whether the client’s binding obligation is a document or a working product, and list each document item separately.

Transcribe the requirements and audit clauses word for word before quoting

The method has two steps. First, before quoting, read the documents the client owes a third party and the original text of the clauses used to audit that obligation, and copy each item’s name, quantity, unit, and format onto one list. Word for word means no rewording: if the requirements say “information security maintenance record report,” the list says exactly that, not a familiar shorthand such as “security report.”

• Document name: copied as written, never reworded.
• Quantity and unit: a set, a file, or a copy, recorded separately.
• Format: PDF, video, or another file format, or a link, each marked.
• Obligation type: whether the item is a document or a working product.

Second, compare that list with the client’s ideas across three columns: whether the client’s plan mentions the item, whether the third-party document requires it, and whether the quote covers it.

A feature that appears in none of the three columns moves out of scope. The comparison table is an internal worksheet and does not go into the quote. Out of scope does not always mean it cannot be done. In one tender, the requirements never mentioned a technical route the development team wanted to pursue, while the same module explicitly listed other items as contractual obligations rather than preliminary research. Preliminary research on that route therefore had to be delivered under document names that appear word for word in the requirements, or it would not pass acceptance.

Cybersecurity rules put outsourcing requirements into contracts and audits

Article 10 of the Cyber Security Management Act requires government agencies and designated non-government entities, when outsourcing the building or operation of information systems or the provision of information services, to select suitable vendors, require vendors to maintain effective security management, supervise it, and set rights, duties, and liability for breach in a written contract (Cyber Security Management Act, 2025). For a vendor, this requirement lands first in the clauses of the contract and the requirements. For criteria on choosing a vendor, see how to choose a software development vendor.

Article 7 of the Enforcement Rules is more specific. When an agency selects and supervises a contractor, it must consider staffing, subcontracting, security testing of custom systems, incident reporting, and data handling at contract termination, and it must audit the contractor periodically or when it learns of an incident (Enforcement Rules of the Cyber Security Management Act, 2026). The text says “immediately” for incident reporting and “periodically” for audits, with no specific number of days, so deadlines come from the requirements and the contract. For maintenance the implication is direct: being audited and checked is expected, so evidence has to be kept in advance. How the two common approaches to security testing differ is covered in vulnerability scanning versus penetration testing.

Agencies are graded too. The Regulations on Classification of Cyber Security Responsibility Levels place each agency in one of five levels, A through E, take the highest level when several apply, and have the agency carry out the tasks listed in the schedules for its level (Regulations on Classification of Cyber Security Responsibility Levels, 2026). The tasks sit in the schedules, which the regulation’s web page does not reproduce, so before drafting requirements a project owner should confirm the agency’s level and read that level’s schedule. The measures from the Administration for Cyber Security (Administration for Cyber Security, 2026) say that an agency that outsources should choose vendors with suitable experience and supervise vendor security practices. That page is marked as under revision, with a new version to be announced, so only this general direction can be cited for now; stage-by-stage detail comes from the contract and the requirements.

Maintenance evidence comes from read-only scripts that write the files themselves

Requirements documents turn maintenance into measurable acceptance indicators and name information security maintenance records among the documents to be produced. The requirements also carried service-level indicators, and indicators like those can only be proven with records that can be produced again and again. The team’s approach is to turn each requirement into a script that writes its own file: once the script has run, a time-stamped file exists, and that file is the evidence. For the maintenance service itself, see Polish+ maintenance.

• Weekly file integrity: compute SHA-256 hashes over the website directory, excluding dependency packages and version-control folders, and compare the result with the previous week. A difference file is kept only when something differs, and only changed files are re-hashed.
• Weekly log digest: a log-summarizing tool compiles the past week’s logs at high verbosity.
• Capacity alert: a notification goes out when disk usage exceeds 90%.
• Monthly report: a system report is produced every month, and has been for more than a year.
• Certificate changes: each change is filed as a document.

These scripts share one trade-off: only packages already on the host and features built into the runtime are used, so nothing extra is installed on the production host. A check should not become a new change.

The restore drill has two more scripts. One checks the application host: service status, the database connection, and the count and size of uploaded files. The other checks the database: the connection, the table list, an exact row count per table, data and index sizes, and the range of primary-key ids. Both are read-only, every output line carries a timestamp and a PASS, FAIL, INFO, or WARN tag, and each run also writes a report file. The scripts were run once on production and once on the standby, and the two reports can be compared table by table. This article describes the drill procedure and output format only, and does not report drill results.

Policy clauses fail on the bypass paths

Password policy is another typical case. The clauses are not hard to write; the hard part is applying the same rules on every sign-in path. Password rules are often rolled out in stages, for example: a new password cannot match any of the previous three, a minimum password age, no match with the account name, no keyboard sequences, a change at least every three months, and a minimum length. The gaps that tend to need closing are bypass paths. Regular sign-in checks whether the password is an initial password or more than three months old, and if third-party sign-in does not get the same check, the rules leave a gap. The same rule also has to be implemented once in the back office and once in the API.

Front-end hints and back-end checks must stay in sync, with the back end as the authority. When a strength rule changed, the front end and back end each changed once, and the explanatory text followed. POLISH works through a checklist clause by clause rather than only changing the registration page.

Working with the competent authority’s scans and appeals

POLISH has supported a Ministry of Education project, working with the scans the competent authority required, fixing medium- and high-risk findings, and filing appeals against false positives, and it has taken over from a design tender into the engineering tender. Project scope is on the Ministry of Education project page.

This kind of support lands after the scan: medium- and high-risk findings get fixed, and false positives get appealed. An appeal needs an explanation that can be checked against records: which request, which version, which setting. The files left by routine maintenance are the material for that explanation.

Incident reports establish mechanism and sequence first, and list what cannot be found

The value of an incident report lies in stating the mechanism and timeline clearly. Take a stalled virtual machine: evidence gathering splits into four stages, with one script and one report per stage.

Stage one established the mechanism: the kernel and existing processes were alive, but creating new processes kept failing. Stages two and three established the sequence: components stopped one after another, from the log service through the security agents and the scheduler to outgoing mail, within about six minutes. Stage four examined the logs of the most suspect component, and before running it the team wrote down how each of two outcomes would be handled.

Two traps are common in evidence collection. One is correcting one’s own reading: if an earlier report misjudged the multiple on a metric, the next report states the correction directly. The other is time format: in one directory some logs may use local time and others UTC, and searching by local time misses the failure window. Three sources cannot be reached from inside the host: the security software console, the management console, and the virtualization platform’s events and performance data. The report lists all three as obtainable only from outside.

Whether or not the root cause can be identified, the report lists systemic risks, such as service liveness alerts, performance monitoring, log rotation and change management on production hosts. The value of the report does not depend on finding the root cause.

This style follows blameless postmortems: the focus is on the conditions that produced the event, not on blaming a person or a team; people who fear punishment tend to hide problems, so a postmortem is material for improving systems and processes, not a penalty (Lunney and Lueder, 2017). On incident response itself, NIST SP 800-61, third revision, places it inside an organization’s cybersecurity risk management, covering preparation, detection, response, and recovery, and supersedes the 2012 second revision (Nelson et al., 2025). The development team files the systemic-risk list under gaps in preparation and detection.

How data from many units becomes one checkable master table is covered in organizing data when ministries share one campaign.

When this does not fit

When the contract involves no system development or operations at all, the approach in this article does not apply: it rests on having a system to deliver and maintain.

Next step: what to prepare

Prepare the materials below, then contact the development team and describe the stage the project is in.

• The requirements document, including the list of documents in its attachments
• The agency’s cybersecurity responsibility level
• A list of existing systems
• A summary of the last security assessment results