Building A Government ICT Compliance Checklist That Works

Government technology teams operate under a web of laws, policies, standards, contracts and internal controls. A compliance checklist turns those requirements into practical tasks that can be assigned, tested and reviewed. Without that structure, an organisation may have sound policies but still struggle to prove that systems, suppliers and staff follow them in day-to-day work.

In Australia, the right checklist depends on the level of government, the type of information handled and the service being delivered. A Commonwealth department may need to consider the Protective Security Policy Framework (PSPF), the Information Security Manual (ISM), the Essential Eight and Australian Privacy Principles (APPs). A council in regional New South Wales or a Victorian health service will face a different combination of state rules, records obligations, procurement conditions and community expectations.

Define The Scope Before Listing Controls

Start by describing the service, system or programme covered by the review. A checklist for a public-facing grants portal will look different from one for an internal finance platform, a data warehouse or a managed network. Record the business owner, users, locations, suppliers, data types, hosting arrangement and interfaces with other systems.

The scope should include the full service lifecycle. This means planning, procurement, configuration, operation, support, change management, decommissioning and disposal. If a Canberra-based department uses a cloud platform hosted partly overseas, the checklist should cover the provider, subcontractors, data transfers and exit arrangements rather than focusing only on the department’s own environment.

Classify information early. Personal information, health records, tax details, payment information, security-sensitive material and commercially confidential data may require different safeguards. The classification should influence access controls, encryption, retention, incident response, logging and supplier due diligence. It also helps prevent a common problem: treating every system as either “secure” or “not secure” without matching safeguards to actual risk.

Map Australian Obligations And Standards

Create a requirements register before writing individual checklist questions. For Commonwealth organisations, relevant sources may include the PSPF, ISM, Essential Eight, Privacy Act requirements, Archives obligations, accessibility expectations and the Digital Service Standard. State and territory agencies may have separate cybersecurity policies, information-sharing rules, records legislation and procurement frameworks. Local councils should check their own jurisdictional requirements instead of assuming that a Commonwealth template applies unchanged.

Standards and frameworks should be linked to the organisation’s operating context. The Essential Eight, for example, provides a practical baseline for reducing common cyber risks, while the ISM contains broader guidance for protecting information and systems. ISO/IEC 27001 can support an information security management system, but certification does not automatically demonstrate compliance with every government obligation.

A useful register gives each obligation a source, owner, applicability decision and review date. Include contractual requirements from whole-of-government panels, software licences, cloud agreements and outsourced service contracts. Requirements can also arise from accessibility commitments, open data policies, records management procedures and internal delegations. This approach keeps the checklist grounded in the actual service instead of copying a generic list from another agency.

Turn Requirements Into Testable Controls

Avoid vague questions such as “Is cybersecurity managed effectively?” They are difficult to answer consistently and produce weak evidence. Replace them with testable statements: “Are privileged accounts protected by phishing-resistant multi-factor authentication?” or “Are critical security patches deployed within the approved time frame?”

Each checklist item should identify the control objective, the expected condition, the test method, the evidence required and the person responsible. A simple status field can use “compliant”, “partially compliant”, “not compliant”, “not applicable” and “pending evidence”. Require a written explanation for every “not applicable” decision, especially where the control relates to high-risk information or a public-facing service.

Controls should be measurable where practical. Examples include the percentage of supported devices receiving security updates, the age of unresolved vulnerabilities, the number of dormant privileged accounts and the time taken to revoke access after a staff member leaves. Metrics help managers see whether compliance is stable or simply the result of a last-minute clean-up before an audit.

Include both preventative and detective controls. Preventative measures might include secure configuration baselines, segregation of duties and approval gates for production changes. Detective measures include centralised logs, vulnerability scanning, access reviews and alerts for unusual activity. A checklist that records only policy approval will miss whether the control works in the live environment.

Gather Evidence That Can Survive Review

Evidence should be specific, current and traceable to the system under review. Suitable material may include policy documents, risk assessments, architecture diagrams, configuration exports, penetration-test reports, training records, access review results, incident tickets, supplier attestations and change approvals. Screenshots can help, but they should show enough context to identify the system, date and relevant setting.

Create an evidence index with a unique reference for each item. Note who supplied it, when it was collected, what control it supports and when it expires. This prevents teams from attaching the same outdated document to several unrelated controls. It also makes an internal audit, funding review or external assurance exercise less disruptive.

Pay attention to operational proof. A policy may say that access is reviewed quarterly, but the stronger evidence is a dated review record showing exceptions, approvals and follow-up actions. Likewise, a backup policy is less persuasive than restoration test results that demonstrate the organisation can recover a service within its agreed recovery objectives.

Digital approvals should be handled carefully. Where a process relies on signed authorisations, digital signatures can strengthen identity verification, integrity and auditability when they are implemented with suitable trust and records controls. The checklist should still confirm who can sign, how certificates are managed, how revoked credentials are handled and how signed records are retained.

Assign Ownership And Manage Exceptions

Every control needs a named owner with enough authority and knowledge to maintain it. Security may own vulnerability management, procurement may own supplier checks, records staff may own retention controls, and a product manager may own service accessibility. A shared responsibility model should state exactly where the agency’s duties end and a cloud provider’s duties begin.

Use a risk-based exception process rather than allowing teams to mark difficult controls as “not applicable”. An exception should explain the business reason, affected systems, risk rating, compensating controls, approval authority, expiry date and review schedule. A temporary exemption for an ageing application may be reasonable if there is a funded replacement plan and additional monitoring. An indefinite exemption with no owner is simply an unmanaged risk.

Leadership support matters because compliance often competes with delivery deadlines and budget pressures. Clear sponsorship helps teams resolve competing priorities, while practical guidance helps staff apply standards without treating them as paperwork. Resources such as leadership and innovation are useful reminders that governance should support responsible improvement rather than block every change.

For Australian agencies, escalation paths should reflect the organisation’s structure. A council may need to involve its general manager, audit and risk committee, state privacy authority or shared service provider. A Commonwealth entity may need security, privacy, accountable authority and portfolio-level involvement. Define these routes before an incident or audit finding occurs.

Review The Checklist Through Evidence And Action

A checklist should be reviewed when systems, suppliers, legislation or threat conditions change, not just once a year. Schedule formal reviews at least annually and trigger additional checks after a major platform upgrade, security incident, merger, change in data use or change to a government policy. The review should examine whether controls remain suitable, whether evidence is still available and whether previous findings were actually closed.

Use short, focused lists to keep review work practical.

Before the assessment

• Confirm the service boundary and information classifications
• Check current legislation, policies, contracts and standards
• Name control owners, approvers and evidence custodians
• Agree testing dates and access to relevant systems

After the assessment

• Record findings with risk, impact and due dates
• Approve exceptions through the proper governance path
• Retest high-risk gaps after remediation
• Report trends and overdue actions to senior management

The following comparison can help distinguish a basic compliance approach from a more dependable operating model.

Area	Basic Approach	Stronger Practice	Useful Evidence
Requirements	Copy a generic standards list	Map obligations to the specific service and jurisdiction	Requirements register
Identity	Require passwords and occasional reviews	Use least privilege, MFA, joiner-mover-leaver controls and privileged access monitoring	Access reports and configuration records
Vulnerability management	Run periodic scans	Prioritise, remediate and verify issues against risk-based time frames	Scan results, tickets and retest records
Suppliers	Collect a security questionnaire	Assess the supply chain, contract controls, assurance reports and exit arrangements	Due diligence file and contract clauses
Privacy	Publish a privacy statement	Link data collection, use, disclosure, retention and breach response to actual workflows	Privacy assessment and data map
Continuity	Maintain a backup policy	Test restoration, recovery time and recovery point objectives	Exercise report and remediation log
Exceptions	Record unresolved gaps	Apply time-limited, approved exceptions with compensating controls	Exception register

A mature checklist is a management tool, not an audit prop. Use its results to prioritise investment, update risk registers, improve procurement specifications and inform service design. When a control repeatedly fails, investigate the underlying cause: unclear ownership, unsuitable technology, insufficient training, poor supplier performance or an unrealistic policy.

Begin with one important service, test the checklist with the people who operate it and refine the wording after the first review. Then extend the model across systems and agencies, keeping evidence requirements proportionate to risk. Build the checklist into ordinary governance and release processes so compliance becomes part of delivering trustworthy public services, rather than a scramble before the next review.