VAPT in Singapore: What Regulators Expect and How to Prepare

In Singapore, VAPT expectations depend on who is asking, but the baseline is consistent: use a properly licensed provider, test at a frequency matched to risk, and keep evidence a regulator can review. The Cyber Security Agency licenses penetration testing as a regulated service, financial institutions work to MAS's Technology Risk Management Guidelines, and the Personal Data Protection Commission treats regular security testing as part of the "reasonable security arrangements" required under the PDPA. None of these frameworks names a single correct tool or product — they expect independence, competence and documented evidence, and it is the organisation's job to show it meets them.

What regulators and frameworks expect

CSA: penetration testing is a licensable service

CSA will license only two types of service providers, namely those providing penetration testing and managed SOC monitoring services as specified in the Second Schedule of the Act, and it is an offence for a cybersecurity service provider to engage in the business of providing a licensable cybersecurity service without a licence. The regime is administered by the new Cybersecurity Services Regulation Office (CSRO), which protects consumers by ensuring high provider standards, and it has applied since the licensing framework took effect from 11 April 2022, when Part 5 of the CS Act and the Second Schedule to the CS Act both came into force.

A useful distinction for buyers: vulnerability assessments usually involve scanning IT systems or networks to identify flaws that may be exploited and do not compromise cyber defences, which is why vulnerability assessment is not a licensable cyber security service. Penetration testing is licensable, and red teaming services that include penetration testing should also be licensed. When you procure VAPT in Singapore, check that the provider — and any subcontractor actually running the test — holds a current CSRO penetration testing licence, not just a vulnerability scanning capability badged as a "test".

CCoP: fixed cycles for CII owners

Owners of critical information infrastructure work to the Cybersecurity Code of Practice. The Cybersecurity Code of Practice for Critical Information Infrastructure – Second Edition (CCoP2.0) has been in effect since 4 July 2022, superseding previous versions of the Code, and it specifies the minimum requirements that a critical information infrastructure owner shall implement to ensure the cybersecurity of the CII. Under CCoP 2.0, testing cadence is set by asset type rather than left to discretion: CII owners must fulfil requirements including penetration testing for operational technology systems, red/purple-teaming and threat hunting, in addition to existing requirements such as risk and vulnerability assessments, with vulnerability assessment and penetration testing due for IT within 12 months and for OT within every 24 months, with the first OT instance due 12 months after the compliance date.

The Code is not static. CSA has confirmed that the CCoP will be further updated with technical guidance covering adversarial attack simulation, penetration testing, and threat hunting, driven partly by the fact that Frontier AI now allows threat actors to discover vulnerabilities faster, shortening the window for exploitation. CIIOs should treat their current VAPT programme as a floor, not a ceiling, and expect the technical guidance to sharpen expectations around scenario realism and reporting.

MAS TRM: risk-proportionate, but not optional

For banks, insurers, payment institutions and other regulated financial institutions, the relevant document is the MAS Technology Risk Management Guidelines. MAS issued the revised Guidelines on 18 January 2021, focused on addressing technology and cyber risks in view of the growing use of cloud technology, application programming interfaces and software development by financial institutions, and they cover the roles and responsibilities of the board and senior management, oversight of third-party vendors, and the monitoring, testing, reporting and sharing of cyber threats within the financial ecosystem.

On testing itself, MAS does not prescribe a single number. The frequency of such tests should be commensurate with the criticality of the IT system and the security risk to which it is exposed — meaning an internet-facing payment gateway and an internal reporting tool will not sit on the same cycle. In practice, most regulated entities run penetration testing annually as a baseline and add testing after material change. Institutions also increasingly reference the Association of Banks in Singapore Penetration Testing Guidelines, which reflect industry best practice and provide a baseline penetration testing framework for financial institutions and their vendors and contractors, alongside recognised methodologies such as OWASP, NIST, the PCI Security Standards Council and ISECOM. MAS inspection teams will ask for evidence: scope documents, test dates, findings, remediation tracking and sign-off — not just a clean summary slide.

PDPC: reasonable security arrangements under the PDPA

The Personal Data Protection Commission does not license VAPT providers, and the Personal Data Protection Act does not name penetration testing directly. But the Act's Protection Obligation requires organisations to protect personal data in their possession by making reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal, or similar risks. The PDPC's Guide to Data Protection Practices for ICT Systems compiles data protection practices from past PDPC advisory guidelines and guides, and includes lessons learnt from past data breaches, and recommends basic and enhanced practices that organisations can incorporate into their ICT policies, systems and processes, with ICT security and testing set out as one of the areas organisations are expected to address. Separately, the Personal Data Protection Commission has made clear through enforcement actions that organisations handling significant volumes of personal data are expected to conduct regular security assessments, so VAPT should not be treated as optional simply because no single clause of the Act uses the term.

IM8: the public sector baseline

Government agencies and their suppliers work to the Instruction Manual for ICT&SS Management. IM8, governed by the Smart Nation and Digital Government Group, sets the foundational security and governance policies for all public sector IT systems and dictates how systems should be architected, managed and secured, and many government agencies derive their audit frameworks directly from IM8 policies. Within that framework, VAPT is treated as a gating control before go-live: systems undergo vulnerability assessment and/or penetration testing — scanning and/or exploitation — with remediation expected for all findings, and waiver justification required for anything that cannot be remediated, supported by evidence such as screenshots, logs, configuration files and scan raw data submitted for review. Vendors bidding for government work should expect VAPT scoping and evidence requirements to be raised at tender stage, not after contract award.

At a glance

← Swipe to compare →

Preparation checklist for a CISO

Whichever regime applies, the preparation steps are similar. A security lead can hand the following to their team before engaging a tester:

1. Confirm which regime actually governs you. A fintech may sit under both MAS TRM and CSA licensing rules as a buyer; a CII owner in energy or healthcare sits under CCoP as well as its sector regulator; any organisation holding personal data sits under the PDPA regardless of sector. Map obligations before scoping the test, not after.
2. Check the provider's licence, not just its marketing. Ask for the CSRO penetration testing licence number and confirm it covers the entity actually performing the work, including subcontractors.
3. Set the cadence to the framework, not the calendar. CII systems have fixed IT/OT cycles; financial institutions should document the risk rationale behind their chosen frequency; government systems need testing built into the release cycle, before acceptance; PDPA-covered organisations should be able to justify their cycle as a reasonable security arrangement if asked.
4. Separate vulnerability assessment from penetration testing in your records. Since CSA treats them differently for licensing purposes, your internal registers and vendor contracts should use the same distinction — scanning versus exploitation.
5. Define scope and rules of engagement in writing. Include environment (production or production-like), testing windows, data handling rules and an incident escalation path, and notify monitoring teams and system owners before testing begins.
6. Track remediation, not just findings. Regulators and auditors look for evidence that vulnerabilities were fixed or formally accepted, with a named owner and a date — an open finding with no action plan is a common audit failure.
7. Retest after significant change. A new release, infrastructure migration or third-party integration resets the clock, regardless of when the last scheduled test ran.
8. Keep evidence in a form you can hand to a regulator. Scope documents, raw scan output, exploitation narrative, retest results and sign-off should be retrievable as a package, not scattered across email threads.

How Infracom helps

Infracom is a Singapore-based cybersecurity consultancy established in 2008, ISO 27001 certified with SQEP services in scope, licensed under the CSA CSRO regime, and recognised as a CREST Pathway+ Organisation — a designation on CREST's structured route toward full accreditation, requiring a self-assessment against organisational standards and a CREST cybersecurity service area, with participants such as ourselves working toward full accreditation on the timelines CREST sets for that stage. We deliver VAPT engagements scoped against the specific regime that applies to your organisation — CCoP cycles for CII owners, MAS TRM-aligned testing for financial institutions, PDPA-driven testing for any organisation handling personal data, or IM8-aligned acceptance testing for public sector projects — with reporting built to withstand regulator and auditor scrutiny. Details of our approach and engagement types are set out on our VAPT services page.