Low-Risk Software as a Service (Saas)

System Characteristics

• Name: Low-Risk Software as a Service System

• Description: A generic system hosted on the cloud by a third-party service provider.

• Security Sensitivity Level: Restricted, Sensitive Normal

AS: Application Security (3)

AS-5: Password Requirements

• Group: Application Security

• Profile Level: 1

Control Statement

Where SSO or passwordless is not supported, verify that [as-5_prm_3] passwords are at least [as-5_prm_1] characters in length and [as-5_prm_2].

Control Recommendations

Latest NIST SP 800-63B (opens in new tab) guidelines found that password length is a primary factor in determining the strength of a password while composition and complexity rules provide marginal security benefits.

Risk Statement

Short or commonly used passwords increase the vulnerability to unauthorised access, potentially leading to compromised accounts and unauthorised activities on the system.

Parameters

AS-6: Password Salting and Hashing

• Group: Application Security

• Profile Level: 1

Control Statement

Store passwords as salted hashes using a password hashing scheme that is resistant to offline attacks such as those described in NIST SP 800-63b (opens in new tab). The salt should be:

1. Generated using a cryptographically secure pseudo-random number generator in accordance with industry standards;

2. At least 32 bits long; and

3. Randomly generated for each account.

Control Recommendations

Refer to NIST SP 800-90Ar1 (opens in new tab) for suitable pseudo-random number generators. Refer to NIST SP 800-63b (opens in new tab) Memorized Secret Verifiers section for suitable hashing schemes, like PBKDF2. For application source code, use a cryptographically secure pseudo-random number generator function instead of an insecure one, such as crypto.randomBytes instead of Math.random in Node.js and java.security.SecureRandom.nextBytes instead of java.util.Random in Java.

Risk Statement

Without salting and hashing, in case of a data breach, exposed passwords can be easily extracted, leading to potential compromise of accounts and sensitive information.

AS-15: Password Change

• Group: Application Security

• Profile Level: 1

Control Statement

Enforce password change upon suspected account compromise.

Control Recommendations

Implement mechanisms to detect signs of account compromise, such as unusual login activity or multiple failed login attempts. Notify users promptly to change their passwords and provide guidance on creating strong, unique passwords. Consider integrating multi-factor authentication to enhance security.

Risk Statement

Failure to enforce password changes upon suspected account compromise increases the risk of prolonged unauthorised access, leading to potential data breaches and exploitation of systems.

ST: Security Testing (2)

ST-1: Vulnerability Assessment

• Group: Security Testing

• Profile Level: 2

Control Statement

Run regular [st-1_prm_1] vulnerability assessment scans for eligible hosts at least every [st-1_prm_2] day(s).

Control Recommendations

Select agent-based or network-based scans as necessary. Implement authenticated scans where possible for greater coverage. For cloud systems, use scanners such as Amazon Inspector or Microsoft Defender for Cloud for continuous scanning of cloud systems. For on-premises systems, subscribe to Vulnerability Management System (VMS). For SaaS, refer to recent vulnerability scanning reports done by the SaaS provider.

Risk Statement

Without regular vulnerability assessment scans, hosts remain exposed to undetected security vulnerabilities or misconfigurations, increasing the risk of exploitation and unauthorised access to critical systems.

Parameters

ST-4: Security Testing Programme

• Group: Security Testing

• Profile Level: 2

Control Statement

Conduct and document a [st-4_prm_1] by internal teams or independent external parties every [st-4_prm_2] day(s).

Control Recommendations

Refer to the WOG Security Testing Guidelines for recommendations on the conduct of security testing engagements. For systems that are permitted to use Government Bug Bounty Programme as an alternative, obtain a passing rating based on the Agency Readiness Scorecard. For SaaS, refer to recent penetration testing reports done by the SaaS provider.

Risk Statement

Without undergoing security testing, there's an increased risk of undetected security weaknesses, leaving the application susceptible to exploitation, data breaches, and unauthorised access.

Parameters

BR: Backup and Recovery (2)

BR-1: Backup

• Group: Backup and Recovery

• Profile Level: 1

Control Statement

Backup all important data and systems at least every [br-1_prm_1] day(s), and store backups in a secure and separate location.

Control Recommendations

Use default CSP-managed backup services (e.g., AWS Backup, Azure Backup, GCP Backup and DR Service). Consider alternative backup services only when default CSP services cannot be used. Store backups and snapshots separately to primary data storage with data encrypted-at-rest. For SaaS, ensure that SaaS provider is able to restore last backup.

Risk Statement

Without regular backups stored in a secure and separate location, there is an increased risk of data loss, system failures, and extended downtime in the event of accidental deletion, hardware failures, or malicious attacks.

Parameters

BR-2: Recovery Testing

• Group: Backup and Recovery

• Profile Level: 2

Control Statement

Conduct testing of recovery processes at least every [br-2_prm_1] day(s) to ensure their effectiveness.

Control Recommendations

Ensure each test verifies the system's ability to fully restore all data and services.

Risk Statement

Failure to regularly test recovery processes may result in ineffective response during actual incidents, increasing the risk of prolonged downtime, data loss, and compromised business continuity in the event of a disaster or system failure.

Parameters

DP: Data Protection (4)

DP-2: Data at Rest Encryption

• Group: Data Protection

• Profile Level: 1

Control Statement

Encrypt data at rest.

Control Recommendations

Many CSP services encrypt data at rest by default but this should be confirmed and validated depending on service usage.

Risk Statement

Without encrypting data at rest, there's an increased risk of unauthorised access and data exposure in the event of physical theft, unauthorised access to storage media, or compromised security controls, compromising the confidentiality of stored information.

DP-3: Data in Transit Encryption

• Group: Data Protection

• Profile Level: 1

Control Statement

Encrypt data in transit.

Control Recommendations

While some CSP services transparently encrypt data in transit at the network layer, data at the application layer should be encrypted using protocols such as Transport Layer Security (TLS) 1.2 and above

Risk Statement

Failure to encrypt data in transit increases the risk of unauthorised interception and eavesdropping, potentially leading to data breaches, unauthorised access, and compromise of sensitive information during transmission.

DP-8: Data Classification Disclosure

• Group: Data Protection

• Profile Level: 1

Control Statement

For internal applications serving public officers, specify the highest permitted security and sensitivity classification for input data, such as text, audio, or multimedia/file uploads, in the system's user interface and guides.

Control Recommendations

Indicate with a clear message, either at or near the input field, the relevant data classification that may be used with the system. For GenAI systems, note that any proposed deviations to this control must be submitted to and approved by NAIG.

Risk Statement

Users who are not informed of the maximum allowed data classification may submit sensitive information the system is not permitted to process, risking data breaches, legal violations, and reputational harm.

DP-10: Secure Data Wipe and Verification

• Group: Data Protection

• Profile Level: 1

Control Statement

Ensure that all government information in resources assigned to Third party are destroyed or securely wiped.

Control Recommendations

Use secure data wiping tools meeting international standards (NIST SP 800-88 or ISO/IEC 27040) for complete data destruction. Obtain documented evidence confirming secure destruction of government information and conduct periodic compliance audit

Risk Statement

Ensuring resources destroy or securely wipe government information reduces the risk of unauthorised access, data leakage, and ensures compliance with data protection and residency requirement.

LM: Logging and Monitoring (5)

LM-2: Tamper-Resistant Log Storage

• Group: Logging and Monitoring

• Profile Level: 1

Control Statement

Protect logs from unauthorised access, modification, and deletion.

Control Recommendations

Apply access control policies to logs based on the principle of least privilege. As far as possible, only read access should be granted and tamper-resistant.

Risk Statement

Without protection measures, logs are susceptible to unauthorised access, modification, or deletion, leading to the risk of tampering, loss of crucial audit information, and compromised forensic analysis capabilities during security incidents.

LM-4: Audit Logging

• Group: Logging and Monitoring

• Profile Level: 1

Control Statement

Log user account activities and system audit events to detect anomalous or unauthorised actions.

Control Recommendations

For cloud, configure CloudTrail for AWS or its equivalents to log management and audit events such as changes to accounts, access, IAM policies and resources. For SaaS and COTS applications, enable audit logging to track account-related activities. Logs should capture activities like authentication events (logins, MFA), access changes (role/permission modifications), and administrative actions (user management tasks). Each log entry should include essential details such as user identity, timestamp, source (IP/device), and the specific activity performed, to support effective monitoring, investigation, and compliance audits. In addition, for SaaS onboarded to WOG Entra or other identity providers, login attempts should be captured at the identity provider level.

Risk Statement

Failure to log account activities may hinder the detection of unauthorised access attempts or successful breaches, and impede effective incident investigation and response.

LM-9: Security Monitoring and Alerting

• Group: Logging and Monitoring

• Profile Level: 1

Control Statement

Configure security monitoring to identify potential security violations or breaches and send automated alerts, and respond to them accordingly.

Control Recommendations

For IaaS/PaaS, enable Amazon GuardDuty, Microsoft Azure Security Center, or their equivalents. For SaaS, implement monitoring and detection capabilities to identify anomalous or unauthorised activities, such as: a) Unauthorised privilege escalation or role changes b) Dormant or inactive accounts becoming active c) Administrative actions performed outside approved change windows. Where supported, integrate SaaS audit logs with centralised logging or monitoring platforms (e.g., SIEM) to enable continuous monitoring and alerting. Where native logging is limited, work with the SaaS provider to obtain visibility into security-relevant events.

Risk Statement

Without configuring security monitoring to identify potential security violations or breaches and send automated alerts, there's an increased risk of delayed or unnoticed security incidents, hindering timely response and mitigation efforts to protect the system from further compromise.

LM-12: Central Security Log Management and Monitoring

• Group: Logging and Monitoring

• Profile Level: 1

Control Statement

Centralise security log management and monitoring with [lm-12_prm_1].

Control Recommendations

Tenants on Government Commercial Cloud (GCC) already have Cloud Service Provider (CSP) tenant security logs stored centrally and available for forwarding to Government Cyber Security Operations Centre (GCSOC). Contact GCSOC for subscription and additional services.

Risk Statement

Lack of central security log management and monitoring increases the risk of delayed or unnoticed security incidents, hindering effective response, and compromising the overall cybersecurity posture.

Parameters

LM-19: Log Sanitisation

• Group: Logging and Monitoring

• Profile Level: 1

Control Statement

Sanitise logs to protect classified and sensitive data before it is recorded in any logging system or shared to any third party.

Control Recommendations

When logging classified and sensitive data, use sanitisation techniques like masking or tokenisation to prevent information from stored in plaintext during log collection and before logs are shared with any third party. This include information such as hostnames, IP addresses, Personal Identifiable Information (PII), credentials, API keys, and payment details.

Risk Statement

Failing to sanitise logs increases the risk of unauthorised exposure or misuse of sensitive information and other confidential data. This exposure could lead to privacy breaches, financial losses, compliance violations and damage to national reputation.

AC: Access Control (13)

AC-1: Principle of Least Privilege

• Group: Access Control

• Profile Level: 1

Control Statement

Deny access by default and grant only the minimum permissions required for authorised accounts or processes to perform a specific function based on the account inventory implemented.

Control Recommendations

Consider attribute- or feature-based access control for greater customisability and granularity. Use automated tools such as AWS IAM Access Advisor or Azure AD Access Review to assist with granular permission management.

Risk Statement

Violating the principle of least privileges increases the risk of unauthorised access, privilege escalation, and potential security breaches due to unnecessary permissions, compromising the overall security posture.

AC-2: Multi-Factor Authentication (MFA)

• Group: Access Control

• Profile Level: 1

Control Statement

Require MFA for [ac-2_prm_1] accounts at login.

Control Recommendations

Ensure that the authentication factors are different and independent of the accessing device. For additional security, consider MFA for privileged actions at the application level (such as step-up MFA challenges via PIAM tools).

Risk Statement

Without requiring phishing-resistant Multi-Factor Authentication (MFA) for remote access, there is an increased risk of unauthorised access, credential theft, and potential compromise of sensitive systems, especially for accounts with elevated privileges.

Parameters

AC-3: Inactive and Expired Accounts

• Group: Access Control

• Profile Level: 1

Control Statement

Disable or remove [ac-3_prm_3] accounts within [ac-3_prm_1] day(s) from last day of authorised use or have not been used for [ac-3_prm_2] day(s).

Control Recommendations

Use automated checks to identify accounts and credentials that should be disabled. Consider using automated workflows such as System for Cross-domain Identity Management (SCIM) or identity lifecycle management tools. For cloud service provider accounts, use tools such as AWS Config iam-user-unused-credentials-check to manage Identity and Access Management (IAM) Users. For accounts belonging to members of public, there is no need to disable accounts after a period of inactivity. For SaaS, in cases where disabled accounts cannot be removed, revoke the access rights of these disabled accounts.

Risk Statement

Failure to disable or remove unused accounts or credentials with elevated access increases the risk of unauthorised access, as dormant accounts may become targets for exploitation, compromising the security of the system.

Parameters

AC-4: Access Review

• Group: Access Control

• Profile Level: 1

Control Statement

Perform an access review [ac-4_prm_1] and remove unauthorised or unnecessary access rights within [ac-4_prm_2] day(s).

Control Recommendations

For application accounts, implement automated review workflows or reports. For cloud service provider accounts and roles, use tools such as AWS IAM Access Advisor or Azure AD Access Review to facilitate and manage access reviews.

Risk Statement

Without regular access reviews and prompt removal of unauthorised or unnecessary access rights, there is an increased risk of lingering access, potential misuse of privileges, and compromised security, impacting the confidentiality and integrity of sensitive data.

Parameters

AC-6: Default Credentials

• Group: Access Control

• Profile Level: 1

Control Statement

Change default credentials prior to first use.

Control Recommendations

Identify any default credentials used in any system components before deploying and change them. Configure end-user systems to prompt for password change on first login after account creation or reset.

Risk Statement

Failure to change default credentials prior to first use increases the risk of unauthorised access, as default credentials are often well-known and targeted by attackers, compromising the security of the system or device.

AC-14: Inventory of Accounts

• Group: Access Control

• Profile Level: 1

Control Statement

Establish and maintain an inventory of all accounts and their access rights managed within the system.

Control Recommendations

Regularly review and update the account inventory to ensure accuracy and completeness. Implement automated tools where feasible to assist in tracking and managing accounts and their access rights. For SaaS, document and implement processes for the management of interactive accounts. The documentation shall include the roles and responsibilities of the Access Rights Coordinator, an access control matrix to identify accounts or roles with excessive privileges, processes for identifying privileged accounts, and procedures for creating, enabling, modifying, disabling, removing, and reviewing accounts and their access rights. It shall also cover procedures to handle staff movement scenarios, including resignation or retirement, termination, role changes within the agency, and extended leave.

Risk Statement

Failure to maintain an accurate inventory of managed accounts increases the risk of unauthorised access, account misuse, and security breaches due to unmonitored or orphaned accounts.

AC-18: Unauthorised Accounts

• Group: Access Control

• Profile Level: 1

Control Statement

Immediately disable and remove accounts that are identified as unauthorised and have not been approved for use.

Control Recommendations

Integrate account management tools with SaaS platforms to enable centralised visibility and control of user accounts where feasible. or leverage the platform's native account management features if integration is not available.

For SaaS platforms utilised by public officers, CAM (Centralized Account Management) ensures security and compliance by automatically removing or disabling user accounts whenever there are changes in the officers' movement records. This includes situations where an officer leaves the service, transfers to a different department, or takes an extended leave of absence.

Perform periodic reviews of user accounts to identify and remove unauthorised or unnecessary access.

Maintain audit logs of account status changes to support monitoring and accountability.

Risk Statement

Failure to remove unauthorised accounts may result in such accounts remaining active and being exploited, increasing the risk of unauthorised access and data breaches.

AC-19: Account Provisioning Control Validation

• Group: Access Control

• Profile Level: 1

Control Statement

Where an account management tool is deployed, validate that accounts can only be provisioned through the tool.

Control Recommendations

For Agency that implements account management tool to manage accounts for its system/platform, configure the system/platform to disable or remove all direct account provisioning capabilities, so that accounts cannot be created outside of the account management tool. Validation testing should attempt to provision an account directly on the SaaS platform without invoking the account management tool and confirm that the attempt is blocked or results in a non-functional account. Reassessment is required whenever changes are made to the SaaS integration or account management tool configuration.

Exception: Direct account provisioning on the system/platform may be permitted for designated break-glass or emergency accounts, where such accounts are required to recover or administer the system/platform in the event that the account management tool, single sign-on (SSO), or supporting identity services are unavailable. Such accounts should be limited in number, subject to enhanced monitoring and controls, and used only for emergency recovery or administrative purposes.

Risk Statement

Direct provisioning on a system/platform bypasses centralised identity governance, creating unmanaged accounts that are invisible to the account management tool. Such shadow accounts cannot be subject to lifecycle controls (e.g., timely disablement, access reviews), increasing the risk of unauthorised access, privilege accumulation, and undetected account misuse.

AC-20: Account Deprovisioning Control Validation

• Group: Access Control

• Profile Level: 1

Control Statement

Where an account management tool is deployed, validate that accounts are disabled through on the last day of authorised use.

Control Recommendations

For Agency that implements account management tool to manage accounts for its system/platform, simulate an account reaching its last day of authorised use and confirm that the account is disabled on the account management tool by end of that day, with the corresponding system/platform access revoked. Test cases should cover staff movement scenarios including resignation, termination, role change, and extended leave.

Risk Statement

Accounts that remain active beyond their authorised period create a window for unauthorised access, whether through continued use by the departing user or exploitation by a third party. Where the account management tool governs access, failure to disable accounts promptly at the point of authorisation expiry undermines the entire access lifecycle control. This risk is heightened for privileged accounts and systems processing sensitive government data.

AC-21: Access Authorisation Control Validation

• Group: Access Control

• Profile Level: 1

Control Statement

Where an account management tool is deployed, validate that access to the system/platform is granted only after the account management tool validates that the user is an authorised user.

Control Recommendations

For Agency that implements account management tool to manage accounts for its system/platform, simulate access attempts under the following scenarios and confirm that access is denied in all cases where the account management tool has not validated the user as authorised. This can include: (i) A user whose account exists on the system/platform but has not been provisioned through the account management tool. (ii) A user whose account has been disabled through the account management tool. Confirm that all authentication methods associated with the account, including interactive login, API tokens, personal access tokens (PATs), OAuth credentials, and other persistent authentication credentials, are revoked or rendered unusable (iii) A user attempts to authenticate through an unauthorised authentication path (e.g. direct local system/platform authentication where SSO is mandated or another authentication mechanism outside the approved identity management workflow), and confirm that access is denied.

Risk Statement

Granting system/platform access without validation by the account management tool breaks the authorisation chain, allowing users who may have had their access revoked, modified, or never formally approved to gain entry. This creates a direct risk of unauthorised access to government data and services, and undermines the integrity of the entire identity and access management framework governing the system/platform.

AC-22: Access Rights Binding Control Validation

• Group: Access Control

• Profile Level: 1

Control Statement

Where an account management tool is deployed, validate that access rights assigned to an account cannot be mapped or inherited by another account.

Control Recommendations

For Agency that implements account management tool to manage accounts for its system/platform, verify that access grants to any account must originate from the account management tool's authorisation workflow and no system/platform mechanism (clone, copy, bulk-assign, API) may be used to grant access that hasn't been authorised through the tool.

Risk Statement

Allowing access rights to be mapped from one account to another creates a pathway for unintended privilege escalation, where a lower-privileged account could inherit elevated rights from another. This undermines the principle of least privilege and breaks the traceability of access rights to individually authorised users. In a SaaS context, this risk is compounded by the difficulty of detecting such mappings without centralised visibility through the account management tool.

AC-23: Password Reuse Restrictions

• Group: Access Control

• Profile Level: 1

Control Statement

Prohibit password reuse for a minimum of [ac-23_prm_1] generations.

Control Recommendations

Configure password policies to enforce a minimum password history of at least three previous passwords.

Prevent users from reusing recent passwords when setting or resetting passwords.

Apply password history settings consistently across all systems and identity providers.

Monitor password policy enforcement to ensure compliance with defined requirements.

Risk Statement

Failure to enforce password reuse restrictions increases the risk of account compromise due to repeated use of previously exposed or weak passwords.

Parameters

AC-24: Account Lockout on Failed Authentication Attempts

• Group: Access Control

• Profile Level: 1

Control Statement

Lock the system account upon [ac-24_prm_1] consecutive failed authentication attempts.

Control Recommendations

Configure account lockout policies to enforce lockout after a defined number of consecutive failed authentication attempts.

Define appropriate lockout duration and reset conditions to balance security and usability.

Apply lockout policies consistently across all systems and identity providers.

Monitor authentication attempts and account lockouts to detect potential brute force or credential stuffing attacks.

Risk Statement

Failure to enforce account lockout controls increases the risk of account compromise due to brute force or repeated unauthorised authentication attempts.

Parameters

PM: Security Programme Management (5)

PM-2: Risk Assessment

• Group: Security Programme Management

• Profile Level: 0

Control Statement

Develop and document a risk assessment by [pm-2_prm_1] and get it approved by [pm-2_prm_2] prior to [pm-2_prm_3] and conduct a review every [pm-2_prm_4] day(s).

Control Recommendations

The Risk Assessment should cover Cyber Risk, Data Risk, Resiliency Risk, Business Risk, Project Risk, Offshore Risk and other types of risk.

Risk Statement

Without developing and documenting risk assessment before the initial full release, there's an increased risk of overlooking potential security threats, vulnerabilities, and regulatory compliance issues, compromising the overall security posture of the system.

Parameters

PM-3: System Security Plan (SSP) Development

• Group: Security Programme Management

• Profile Level: 0

Control Statement

Develop and maintain a comprehensive System Security Plan (SSP) that accurately reflects the system characteristics and security controls in place for the organisation's systems and environments.

Control Recommendations

Agencies should develop System Security Plan (SSP) as early as possible to identify risks at early stage and ensure necessary controls are in place to reduce them, prior to system or product go-live. The SSP should be detailed, covering all aspects of security controls, roles, responsibilities, and operational processes. Regular updates are necessary to reflect changes in the security landscape and system evolution.

Risk Statement

Failure to develop a comprehensive SSP at early stage can result in inadequate documentation and security controls, leading to increased vulnerability to cyber threats and non-compliance with regulatory requirements.

PM-4: Approval of Residual Risks

• Group: Security Programme Management

• Profile Level: 0

Control Statement

Get acceptance and approval of the residual risks from agency's [pm-4_prm_1], and review and seek approval every [pm-4_prm_2] days.

Control Recommendations

Agencies should seek acceptance and approval from their [pm-4_prm_1] on the residual risks based on the SSP and inform GovTech of the approval.

Risk Statement

Failure to seek the right level of authority to accept and approve the residual risks regularly can lead to misalignment of the business implications and trade-offs from the controls set in the SSP with the Agency IDSC direction.

Parameters

PM-5: Central Submission of Approved System Security Plan (SSP)

• Group: Security Programme Management

• Profile Level: 0

Control Statement

Submit approved SSPs centrally to maintain a unified and up-to-date repository of security plans and practices.

Control Recommendations

Use a central submission channel for SSPs.

Risk Statement

Inconsistent or decentralised submission of the SSP can lead to decreased visibility of security and compliance adoption across Government.

PM-7: Certification

• Group: Security Programme Management

• Profile Level: 1

Control Statement

Ensure that the Software as a Service (SaaS) provider is certified with [pm-7_prm_1]].

Control Recommendations

Ensure that the certification is up-to-date. Avoid certifications that are only attestations without a pass/fail element.

Risk Statement

Third-party certification provides assurance that security controls have been properly implemented in the Software as a Service (SaaS) provider.

Parameters

SA: SaaS Security (4)

SA-1: Supplier Assessments and Reviews

• Group: SaaS Security

• Profile Level: 0

Control Statement

Seek an assessment by [sa-1_prm_1] on the risks associated with suppliers or contractors before using or subscribing to the service.

Control Recommendations

Submit SaaS usage via the Request for SaaS FormSG and the data residency assessment outcome will be provided within 3 working days.

Risk Statement

Failure to assess suppliers may introduce supply chain risks associated with data residency and jurisdiction.

Parameters

SA-2: SaaS Account Management Tool Validation Testing

• Group: SaaS Security

• Profile Level: 1

Control Statement

Conduct validation tests on systems managed through the account management tool.

Control Recommendations

Validation tests should minimally verify that account provisioning can only be performed through the account management tool and not directly on the SaaS platform; accounts on the account management tool are disabled on their last day of authorised use; access to a SaaS is granted only after the account management tool validates that the user is an authorised user; and access rights granted to an account cannot be mapped to another account. Validation tests have to be conducted whenever there are changes that impact the management of accounts on SaaS.

Risk Statement

Failure to conduct validation testing of account management integrations with SaaS may result in unauthorised account provisioning, delayed deactivation, and improper access rights, increasing the likelihood of security breaches and unauthorised data access.

SA-3: SaaS WOG Credential Storage Restriction

• Group: SaaS Security

• Profile Level: 1

Control Statement

Do not store Agency WOG credentials, such as passwords and private keys, in the SaaS, except for WOG-managed identity management services.

Control Recommendations

Implement secure credential management practices. Use approved identity federation.

Risk Statement

Storing WOG credentials in third-party SaaS platforms may result in credentials being exposed or compromised, increasing the risk of unauthorised access, data breaches, and misuse of critical security information.

SA-4: SaaS Provider Encryption or Bring Your Own Key (BYOK)

• Group: SaaS Security

• Profile Level: 1

Control Statement

Use strong cryptographic algorithms that are industry-recognised.

Control Recommendations

Establish cryptographic key management procedures aligned with NIST SP 800-57. Regularly review and update cryptographic implementations based on NIST recommendations and emerging threats.

Risk Statement

Failure to implement proper encryption or manage keys securely may result in unauthorised access to sensitive data, increasing the risk of exposure and breach, particularly if encryption keys are compromised or mismanaged.

GA: Generative AI (11)

GA-10: External AI SaaS - Data classification

• Group: Generative AI

• Profile Level: 0

Control Statement

If using an external AI Software-as-a-Service (SaaS), apply the following requirements based on the security and sensitivity classification of the data being processed by the service.

CONFIDENTIAL (CLOUD-ELIGIBLE) or SENSITIVE-HIGH data: Use only services hosted in Singapore, or services whitelisted by GovTech. Obtain a legally binding Zero Data Retention (ZDR) commitment from the SaaS provider for data processed by AI models and related services before, during or after model inference (e.g. embedding, reranking, web search, guardrail and post-processing services).

RESTRICTED or SENSITIVE-NORMAL data: Obtain a legally binding ZDR commitment from the SaaS provider for data processed by AI models and related services before, during or after model inference (e.g. embedding, reranking, web search, guardrail and post-processing services).

ZDR commitments by SaaS providers must be set out in the relevant agreement(s) governing the use of the service. The agreement(s) must require that input and output data processed by the AI models and related services supporting the SaaS application’s generative AI functions are not logged, stored, or retained for more than 24 hours for any purpose, nor used for model training or improvement.

Control Recommendations

Use services hosted in Singapore where possible.

Verify data security and sensitivity classification with data owner before using data with external SaaS.

Verify where AI models and related services are hosted with SaaS providers before using their services.

Refer to the Annex below for further guidance on obtaining a legally binding ZDR commitment, configurations that may be required for ZDR terms to take effect, definitions, and exceptions.

Risk Statement

Government data processed by external SaaS may be exposed to unauthorised access, disclosure, misuse, or retention, particularly where the service is hosted overseas, or the provider is not legally bound to limit data retention and use.

GA-14: Application safeguards - File uploads

• Group: Generative AI

• Profile Level: 1

Control Statement

If file uploads are enabled, implement safeguards to prevent users from uploading files that, individually or collectively, exceed the data classification permitted for the generative AI application.

Control Recommendations

Implement safeguards best suited to your use case, e.g.:

(1) Data Loss Protection (“DLP”) tools to monitor file uploads;

(2) Restricting bulk or batch file uploads, or requiring users to confirm the security and sensitivity classification of individual files before uploading them;

(3) Prompting users who upload large files to review their contents and the collective security and sensitivity classification.

Any proposed deviations to L1 controls must be submitted to the AI Development Group (AIDG).

Risk Statement

File uploads increase the risk of the generative AI application processing data above its permitted classification, for example where a higher-classified file is uploaded inadvertently, or multiple files are uploaded without considering their collective classification.

GA-15: Application safeguards - Consequential actions

• Group: Generative AI

• Profile Level: 1

Control Statement

For generative AI applications capable of executing consequential actions, implement appropriate safeguards that prevent or limit the potential consequences of errors, and enable their timely detection and recovery.

An action is consequential where, if executed incorrectly, it could have wide-reaching effects, result in serious harm or adverse effects, or be difficult to reverse or recover from.

Control Recommendations

Assess the reach, impact and reversibility of actions that the generative AI application can execute.

(1) Reach: the extent to which the effects of an action can extend beyond the immediate task or use

(2) Impact: the severity of harm or adverse effects that could result from incorrect execution

(3) Reversibility: the extent to which the effects of an action can be readily reversed or recovered from.

Implement appropriate safeguards based on the assessed risks. e.g.:

(1) Restricting the scope, permissions, frequency or scale of actions

(2) Providing action previews

(3) Maintaining appropriate logging and monitoring

(4) Implementing pause, rollback or other recovery mechanisms

(5) Requiring user confirmation or approval before execution where appropriate. Where this is not appropriate or feasible, implement other safeguards to restrict the scope and impact of the action and enable timely detection and recovery from errors.

Any proposed deviations to L1 controls must be submitted to the AI Development Group (AIDG).

Risk Statement

Without appropriate safeguards, erroneous or unintended AI actions may have wide-ranging or serious consequences, or result in effects that are difficult to reverse or recover from. This may cause operational, security, financial, legal, regulatory, service delivery or reputational harm.

GA-16: Application safeguards - Handling of web content

• Group: Generative AI

• Profile Level: 1

Control Statement

Implement safeguards that ensure that any content retrieved from the live web is treated as untrusted reference data, cannot be interpreted or executed as instructions, and does not override or alter the generative AI application’s intended behaviour.

Control Recommendations

Process externally retrieved content from the web through sanitisation, filtering, or guardrail checks before it is passed to the AI system. Remove or neutralise hidden prompts, prompt injections, embedded instructions, or other malicious content in retrieved data. Wrap retrieved content in explicit data boundaries and instruct the AI system to use it only as reference material.

Any proposed deviations to L1 controls must be submitted to the AI Development Group (AIDG).

Risk Statement

Content retrieved from the live web may contain malicious or hidden instructions, including indirect prompt injections. If interpreted as instructions by the generative AI application, such content may manipulate application behaviour, override intended instructions or safeguards, trigger unauthorised actions, or result in unsafe or unauthorised output.

GA-17: Application safeguards - Provenance of web content

• Group: Generative AI

• Profile Level: 1

Control Statement

Record the provenance of any web content retrieved by the generative AI application, such that its sources and use can be traced and reconstructed for auditability, investigation, and accountability.

Control Recommendations

Configure the application to capture structured event logs covering key user interactions, model or agent tool calls, classification of files uploaded, and all other actions relevant to the specific system or use case. Record web sources accessed by the AI system and sources shared with users. Ensure logs are tamper-resistant, access-controlled, retained according to organisational policy, and available for independent audit or incident investigation.

Any proposed deviations to L1 controls must be submitted to the AI Development Group (AIDG).

Risk Statement

Without provenance tracking, product teams may be unable to reconstruct AI system activity, verify the origin of outputs, investigate incidents, detect misuse, or demonstrate compliance with governance, security, and audit requirements.

GA-18: Application safeguards - Accuracy of output and actions

• Group: Generative AI

• Profile Level: 1

Control Statement

Define appropriate accuracy targets for the application based on its specific use case and risks. Test the application’s output and actions against these standards. Implement measures or guardrails to ensure application meets these accuracy standards.

Control Recommendations

Define what constitutes accurate performance for the use case.

Determine appropriate accuracy standards for generated output and (if applicable) actions taken.

Test and measure accuracy using clearly defined metrics, test scenarios, and acceptance criteria.

Implement measures or guardrails to reduce inaccuracy and/or the impact of inaccurate content.

Repeat testing and monitor accuracy following any updates to models, system prompts, connected tools, or other dependencies.

Refer to the Annex below for further guidance on accuracy testing methods and suitable measures.

Any proposed deviations to L1 controls must be submitted to the AI Development Group (AIDG).

Risk Statement

Generative AI models have the potential to ‘hallucinate’, i.e. present false, misleading, or out-of-date information as factually correct. This could cause misunderstandings, affect the delivery of Government policies, functions, or services, or have other negative implications where the information is relied on.

GA-19: Application safeguards - Safety of output and actions

• Group: Generative AI

• Profile Level: 1

Control Statement

Identify safety risks relevant to the application based on its specific use case and risks. This may include malicious input that manipulate the application’s behaviour; harmful, toxic, discriminatory, illegal or otherwise inappropriate output; and unsafe or unauthorised actions. Define appropriate safety standards for the application based on the potential impact of these risks, test the application‘s output and actions against these standards, and implement measures or guardrails to meet them.

Control Recommendations

Assess the nature and potential impact of each identified safety risk, including potential harm to persons, data, or systems.

Determine appropriate safety standards for generated output and (if applicable) actions taken.

Test and measure safety using clearly defined metrics, test scenarios or relevant adversarial or malicious input, and acceptance criteria.

Implement measures or guardrails to meet the defined safety standards, including to inspect and block prompt injections in user prompts and external content before use by the AI system. Use the AI system’s native prompt injection detection capabilities where available, such as Microsoft Defender Prompt Shield for Copilot. Where native capabilities are unavailable or insufficient, implement additional AI guardrail tools such as AWS Bedrock Guardrails, Azure Prompt Shield, or guardrails provided by GovTech.

Repeat testing and monitor safety following any updates to models, system prompts, connected tools, or other dependencies.

Refer to the Annex below for further guidance on safety testing methods and suitable measures.

Any proposed deviations to L1 controls must be submitted to the AI Development Group (AIDG).

Risk Statement

Generative AI applications may produce harmful, toxic, discriminatory, or otherwise inappropriate output, or execute unsafe or unauthorised actions. This may result from the behaviour of the underlying models or from malicious inputs, such as prompt injection, that manipulate the application into disregarding intended instructions or safeguards. This may cause harm to persons, result in unauthorised access to, disclosure, modification, or misuse of data, or adversely affect systems, services or operations.

GA-20: Application safeguards - Quality of output and actions

• Group: Generative AI

• Profile Level: 1

Control Statement

Define what constitutes quality output for the generative AI application, such as relevance, coherence, clarity, appropriate tone and format, alignment with user intent, or successful completion of the intended task. Define appropriate output quality standards for the application based on the application’s use case, test the application‘s output and actions against these standards, and implement measures or guardrails to meet them.

Control Recommendations

Identify the types of poor-quality performance that may arise based on the application’s core function and establish clear standards and acceptance criteria to ensure the application remains fit for purpose and users’ needs.

Test output and action quality using clearly defined metrics, test scenarios and acceptance criteria. The complexity and structure of testing should be tailored to the application’s risk profile.

Implement measures or guardrails to improve quality and reduce the impact of poor-quality outputs or actions.

Document the standards, testing approach, measures or guardrails implemented, and results. Measure and monitor quality and repeat testing after relevant model, prompt, tool, data source or other dependency updates.

Refer to the Annex below for further guidance on output quality testing methods and suitable measures.

Any proposed deviations to L1 controls must be submitted to the AI Development Group (AIDG).

Risk Statement

Generative AI models may produce poor quality output that is irrelevant, incoherent, unclear, or inappropriately presented, or execute actions that are misaligned with the user’s intent. This may reduce the usefulness and effectiveness of the application, and/or prevent it from performing its intended function.

GA-21: Deployment and use - Disclaimers on beta status

• Group: Generative AI

• Profile Level: 2

Control Statement

When a generative AI application is made available to users for testing prior to deployment, inform users (1) of the experimental/beta status of the application, (2) that it is still undergoing testing and refinement, (3) and that it may have errors or vulnerabilities.

Control Recommendations

Provide a clear disclaimer or label wherever users interact with the application, explaining that the application is still undergoing testing and refinement ahead of full deployment. Tailor the label to how users interact with the application, such as a banner for a web-based interface or a spoken disclaimer for a voice-based application.

Risk Statement

Users may over-rely on an application that is still undergoing testing if they are not informed that it may contain errors or vulnerabilities, increasing the risk of harm or reputational impact if the application does not perform as intended.

GA-22: Deployment and use - Disclaimers on risks and limitations

• Group: Generative AI

• Profile Level: 2

Control Statement

When a generative AI application is made available to users, whether for testing or deployment, inform users of the risks and limitations of generative AI, including the possibility of inaccurate or fabricated output (hallucination).

Control Recommendations

Provide users with a prominent disclaimer or label on the risk of inaccurate generative AI output. Present the disclaimer in a form appropriate to the application, such as a visual disclaimer for a web-based interface or a spoken disclaimer for a voice-based application.

Include clauses on the risk of inaccurate or fabricated output in the application’s Terms of Use.

Require users to explicitly acknowledge the risks of using generative AI before using the application, such as by selecting a checkbox or clicking an “I Agree” button.

Ensure that educational materials, such as documentation, guides, playbooks or workshops, highlight responsible use and best practices for users of the generative AI application.

Any proposed deviations to L1 controls must be submitted to the AI Development Group (AIDG).

Risk Statement

Users who are not informed of the risks and limitations of generative AI may over-rely on or trust inaccurate model-generated outputs.

GA-23: Deployment and use - Risk acceptance and approval

• Group: Generative AI

• Profile Level: 0

For Internal Use

TP: Third Party Management (1)

TP-4: Contracts to Govern Third-Party Scope and Responsibilities

• Group: Third Party Management

• Profile Level: 1

Control Statement

Establish contracts or equivalent instruments with third parties to define and govern the scope, responsibilities, security requirements, and compliance obligations for vendor-assigned work.

Control Recommendations

Agencies should utilise Standard ICT Contract Templates with contract clauses covering: scope of work and service levels; data handling procedures across environments; monitoring SOPs and audit rights; incident reporting and breach protocols; governance and compliance requirements; subcontractor management with approval and disclosure obligations; and business continuity planning including joint emergency exercises for critical systems.

Agencies should consider engaging offshore resources through a local Third Party selected from GovTech’s bulk tender. If Agencies are not able to engage offshore resources through a local Third Party selected from GovTech’s bulk tender, Agencies should ensure that the relevant offshore development contractual provisions from the ICT Contract Template for Offshore Development are incorporated in the contract. On award of the contract or equivalent instrument, Agencies can consider to include the following into their exit management plans:

(a) Obligations of the Third Party during the transition period, including transfer of knowledge, deliverables, or services to another Third Party or to the Agency; (b) Option for the Agency to buy back equipment and software from the Third Party based on a formula for price determination; (c) Transfer of relevant sub-contractor contracts and leases (e.g., maintenance and licensing contracts) to another Third Party or to the Agency (d) Transfer of data, data structures and methodologies to another Third Party or to the Agency; (e) Transfer or critical Third Party staff to another Third Party or to the Agency; (f) Destruction of data by the Third Party; (g) Retrieval of any assets that are provided to the Third Party; and (h) Any other agency-specific requirements to be adhered to by the Third Party.

Risk Statement

Establishing contracts or equivalent instruments using standardised templates ensures consistent vendor obligations, clear accountability, and robust legal frameworks, thereby strengthening project success and security posture.