Singapore Government ICT&SS Policy Reform Control Set in OSCAL Format

Introduction

The Singapore Government ICT&SS Policy Reform is the modernised replacement for Instruction Manual 8 (IM8), the Singapore Government's information and communications technology security policy. It defines a Cybersecurity control catalog and a set of System Security Plans (SSPs) that scope those controls by system type and risk materiality.

The authoritative source is:

https://info.standards.tech.gov.sg/

The Open Security Controls Assessment Language (OSCAL) was developed by the National Institute of Standards and Technology (NIST) to enable automation of risk management and compliance frameworks based on security controls and functional requirements, such as SOC 2, FedRAMP, ISO-27001, StateRAMP, CMMC, HIPAA, and PCI. OSCAL is an open machine-readable information exchange format that enables tools to interoperate. More info on OSCAL is available at:

https://pages.nist.gov/OSCAL/

Unusually, GovTech does publish OSCAL — at GovTechSG/tech-standards. The problem is that it has fallen behind the portal. Those files are dated 2025.05.13; the portal is at 2026.03.26. In between: 25 controls added, three groups added (Generative AI, Human Resource, Resiliency), one group dropped (Third Party Management), 17 parameters added, 44 pieces of control prose rewritten — and no profile at all for the High-Risk Cloud CII SSP, which the portal has published since March 2026.

We wrote some scripts which regenerate the OSCAL from the portal. In this repository we provide:

• the Cybersecurity control catalog, current as at the portal's own date, under two identities so it can be consumed either way
• OSCAL profiles for each of the three cloud SSPs at each of its three levels, including the three High-Risk Cloud CII profiles that have no upstream equivalent
• resolved OSCAL profile catalogs for all of the above
• all of it in JSON, XML and YAML

While unofficial, we have published this openly to support Singapore Government agencies, their delivery partners, and the security and compliance engineers and GRC analysts working to these standards, in using compliance automation tooling.

If you have questions - raise an issue or send us an email.

About this repository

This repository is a passive publishing destination — no build or sync logic lives here. The OSCAL artifacts are produced by the scripts in the sibling sg-ictss-oscal-builder project and pushed here by that project. If you are interested in those scripts, please contact the maintainer.

Contents

Last updated: 2026-08-29

The directory layout mirrors GovTechSG/tech-standards, and filenames match theirs exactly, so every profile's trestle://catalogs/… href resolves here without rewriting and the tree can be dropped into that repository as-is. The version lives in each document's metadata.version, not in its filename. All artifacts target OSCAL 1.1.2, matching what GovTech publishes.

catalogs/     the control catalog, two identities, 3 formats  =  6 files
profiles/     9 profiles × 3 formats                          = 27 files
resolved/     9 resolved profile catalogs × 3 formats         = 27 files

The catalog

156 controls across 17 groups, from the portal's Cybersecurity control catalog.

Artifact	JSON	XML	YAML
Cybersecurity Control Catalog	catalogs/cybersecurity.json	.xml	.yaml
Instruction Manual 8 Reform	catalogs/im8-reform.json	.xml	.yaml

Two files, identical bodies, different identity. cybersecurity.json uses the portal's current name and its own UUID, matching how the portal now structures things and leaving room for a DSS catalog beside it. im8-reform.json keeps the legacy title and the upstream UUID, so it is a drop-in replacement for the file in GovTechSG/tech-standards. The profiles here import the legacy path. Two OSCAL documents must never share a UUID, so the retitled primary has its own.

Group		Controls
AC	Access Control	16	Controls to protect against unauthorised access to agency systems.
AS	Application Security	15	Controls to prevent application vulnerabilities caused by insecure coding.
BR	Backup and Recovery	6	Controls to support backup and disaster recovery.
CK	Cryptography, Encryption and Key Management	4	Controls to secure cryptographic protocols.
CS	Container Security	11	Controls to secure container building, distribution, and deployment.
DC	Datacentre	2	Controls to secure datacentre system components.
DP	Data Protection	8	Controls to protect the data of a system.
GA	Generative AI	8	Controls for the use of generative AI/LLMs within applications.
HR	Human Resource	3	Controls for human resources.
IS	Infrastructure Security	14	Controls to secure infrastructure that host applications, services, and data.
LM	Logging and Monitoring	21	Controls to support detection and response to security and operations incidents.
NS	Network Security	11	Controls to secure the network boundaries of a system.
PM	Security Programme Management	10	Controls to implement cybersecurity governance, risk, and compliance processes and policies.
RS	Resiliency	3	Controls for resiliency.
SC	Software Supply Chain	9	Controls to prevent tampering and improve the integrity of the software supply chain.
SD	Secure Development	10	Controls to secure the development pipeline and perform source code quality assurance.
ST	Security Testing	5	Controls to validate the security of a system via internal and external testing.

Each control carries its statement as parts[name=statement], its recommendations as parts[name=guidance], and its risk statement as a risk-statement prop. 58 parameters are declared across the catalog, using OSCAL's {{ insert: param, … }} placeholders in statement text. 110 controls carry rel="reference" links into a 50-resource back-matter covering MVSP, NIST SP 800-53, NIST SP 800-63, the IM8 clause library and Singapore government circulars.

Profiles and resolved profile catalogs

For each risk tier and level: an OSCAL profile document (selecting control ids) and a resolved profile catalog (the filtered catalog itself, with empty groups pruned and back-matter reduced to what the retained controls reference).

SSP	Level	New at this level	Cumulative	Profile	Resolved profile catalog
Low-Risk Cloud	0	7	7	profiles/low-risk-level-0.*	resolved/low-risk-level-0-resolved-catalog.*
Low-Risk Cloud	1	78	85	profiles/low-risk-level-1.*	resolved/low-risk-level-1-resolved-catalog.*
Low-Risk Cloud	2	32	117	profiles/low-risk-level-2.*	resolved/low-risk-level-2-resolved-catalog.*
Medium-Risk Cloud	0	26	26	profiles/medium-risk-level-0.*	resolved/medium-risk-level-0-resolved-catalog.*
Medium-Risk Cloud	1	68	94	profiles/medium-risk-level-1.*	resolved/medium-risk-level-1-resolved-catalog.*
Medium-Risk Cloud	2	23	117	profiles/medium-risk-level-2.*	resolved/medium-risk-level-2-resolved-catalog.*
High-Risk Cloud CII	0	61	61	profiles/high-risk-level-0.*	resolved/high-risk-level-0-resolved-catalog.*
High-Risk Cloud CII	1	60	121	profiles/high-risk-level-1.*	resolved/high-risk-level-1-resolved-catalog.*
High-Risk Cloud CII	2	16	137	profiles/high-risk-level-2.*	resolved/high-risk-level-2-resolved-catalog.*

* is json, xml or yaml.

Levels are cumulative by import chain, not by enumeration. A level-N profile lists only the controls the SSP page assigns to level N and pulls everything below in via include-all on the level-(N−1) profile. Read the "new at this level" column for what a profile document contains, and "cumulative" for what it resolves to. The resolved catalogs hold the cumulative set, which is what an assessor wants.

The level semantics are GovTech's:

• Level 0 — central oversight. Agencies cannot deviate.
• Level 1 — a standard secure product. Deviations need approval from the agency's ICT and Digitalisation Steering Committee or a delegate (CIO/CISO), documented in a custom SSP and submitted centrally.
• Level 2 — extends security and maturity. Deviations need documenting but not approving.

The High-Risk Cloud CII profiles are new. The portal has published the High-Risk Cloud CII SSP since March 2026; GovTechSG/tech-standards has never had a matching profile. These three are that gap filled.

Cross-framework references

References are structured, not prose. The catalog's back-matter holds 50 resources — MVSP, NIST SP 800-53 Rev. 5, NIST SP 800-63B, SP 800-56A/B/C, SP 800-57, FIPS 140-3, CIS Critical Security Controls v8, the Cloud Controls Matrix v4, SLSA, OWASP, CSA and CISA material, the IM8 clause library, and Singapore government circulars — and 110 controls point at them with rel="reference" links whose text carries the specific clause.

This makes crosswalks queryable. For example, every control citing the IM8 Cloud Security clause library:

jq -r '.catalog.groups[].controls[]
       | select(.links[]? | select(.href == "#da71948e-4dff-4a9d-a645-69ced821fe97"))
       | "\(.id)  \(.title)"' \
   catalogs/cybersecurity.json

Or the level-0 baseline for High-Risk Cloud CII, with full control text:

jq -r '.catalog.groups[] | .title as $g | .controls[]
       | "\($g): \(.id) — \(.title)"' \
   resolved/high-risk-level-0-resolved-catalog.json

Validation

These artifacts are validated before publication. Every file here has been checked against:

• the NIST OSCAL 1.1.2 JSON Schema (catalog and profile)
• the NIST OSCAL 1.1.2 XSD
• YAML/JSON structural equality
• XML/JSON control-set equality
• profile import-chain resolution — every selected control id exists in the catalog, every imported document exists
• resolved-catalog versus profile-selection equality
• catalog structural invariants — unique ids, no truncated statements, parameters declared iff referenced, no dangling back-matter links
• control-by-control fidelity back to the portal pages the build read

Status at last publish: 100 checks, 0 failures, 20 JSON and 20 XML documents valid, 156/156 controls verified against the source.

Two independent runs — one live from the portal, one from the pinned HTML snapshot — produce byte-identical catalogs and profiles.

That said, validate independently before feeding these into tooling that will reject invalid input silently — oscal-cli, compliance-trestle, or NIST's online OSCAL validator are all reasonable second opinions.

What we found while building this

Regenerating a published framework tends to surface things. Four are worth flagging to anyone relying on the upstream OSCAL.

1. Three control statements in the published catalog are truncated. GovTechSG/tech-standards at 2025.05.13 ends three control statements at a colon, with the enumerated requirements missing entirely:

Control	Published statement ends	What the portal says
as-6 Password Salting and Hashing	"…The salt should be:"	four salt requirements (CSPRNG, ≥32 bits, per-account)
ns-6 TLS Certificate Validity	"…deployed SSL/TLS certificates are:"	four certificate requirements (trusted root, domain match, not expired, not revoked)
st-5 Vulnerability Remediation	"…within the following timeframe based on severity:"	the four parameterised severity timeframes

Anyone consuming the OSCAL rather than the website has an incomplete requirement for password hashing, certificate validation and vulnerability remediation SLAs. The artifacts here restore all three. Note that this means a diff against upstream shows content appearing, not merely changing.

2. One back-matter link in the published catalog points at nothing. ac-2 links to #9749c983-5562-4a6f-8852-7eecf9b38d2c3 — a valid resource UUID with a stray character appended. The intended target is unambiguous (IM8 On-Premise Application Development Security (ADS) (For Non-S)), and it is repaired here.

3. Terminology shifted across the catalog. A large share of the 44 prose changes are a deliberate vocabulary move — external users → Public Users, internal users → a new parameter, short-lived → time-restricted, user → account — plus several controls generalised away from Singapore-specific infrastructure (GCC → cloud, Government → organisation, a GIROC reference replaced with NIST SP 800-61). dp-4 is rewritten end to end, from "host CONFIDENTIAL systems in GCC" to "implement a centralised cloud tenant management structure". If anything downstream quotes control text, it needs re-reading, not just re-diffing.

4. Third Party Management is gone. The published profiles select six tp-* controls. The portal no longer publishes that group in the Cybersecurity catalog, and the controls are not in the Digital Service Standards catalog either. Their subject matter — SaaS SLAs, offshore development scope, supplier assessment, third-party audit, attestation reports — has no equivalent among the 25 new controls, so this is a removal rather than a renumbering. The portal is self-consistent: the current SSP pages no longer select TP either. Only the stale profiles do.

Known caveats

• 46 controls carry no reference links. The portal does not publish the rel: reference cross-walk at all, so links can only be carried forward from the prior OSCAL by control id. The 25 controls added since 2025.05.13 — the whole of Generative AI, Human Resource and Resiliency among them — have none, and neither do 21 pre-existing controls that never had any. No tool can fix that; it needs GovTech.
• The High-Risk profiles carry no party attribution. Each published GovTech profile names a working group with civil servants' email addresses. There is no published High-Risk equivalent, and copying another tier's group into a compliance artefact would be a false attribution, so the roles, parties and responsible-parties blocks are omitted. This is valid OSCAL and an honest gap, not an oversight.
• XML and YAML profiles import their own format. A JSON profile imports the JSON catalog, an XML profile the XML catalog. This is the one place the three serialisations of a document deliberately differ.
• Resolved catalogs are produced natively, not by an OSCAL profile resolver. The profiles use only import + include-controls/include-all with as-is merging and no modify, and each resolved catalog is asserted equal to its profile chain's selection. If you need canonical resolution, run the profiles through oscal-cli.
• The Digital Service Standards catalog is not here. The portal publishes a second catalog at /control-catalog/dss/ (9 groups, 92 controls). No profile currently imports it and it has no prior OSCAL to merge from, so it is out of scope for now.
• Dates. metadata.version is the source page's own "Last updated" date — 2026.03.26 for the catalog, 2026.03.24 for the profiles — and last-modified is that date at 00:00:00+08:00. The published upstream files use 18:00:00+08:00, which appears arbitrary.

Copyright

The Singapore Government ICT&SS Policy Reform control set is published by the Government Technology Agency of Singapore (GovTech). Framework content is copyright GovTech and its licensing terms govern any redistribution of these derivative artifacts. The prior OSCAL these artifacts merge from is published at GovTechSG/tech-standards under the MIT licence.

The OSCAL derivative artifacts in this repository are created by independent security and compliance engineer Baden Hughes. They are a mechanical transformation of published material and add no framework content.

This is an unofficial conversion. It is not endorsed by, affiliated with, or supported by GovTech.