What evidence do MAS Technology Risk Management guidelines expect?

The MAS Technology Risk Management Guidelines, issued in January 2021, set expectations for financial institutions in Singapore. They do not list evidence artifacts. You infer them from the wording: where a section says "should establish" a process or standard, keep the document, the review record and proof it runs.

Are the guidelines a checklist you can pass?

Not exactly. The text is written as guidance with "should" statements, and no certificate comes from it. Supervisors judge whether your practice fits the size, risk and criticality of your systems. Evidence therefore means being able to show, for each relevant section, a written standard, an owner, and records that the standard operates.

This post covers the sections engineering and security teams touch most. It is a reading aid, not legal advice, and your regulator contact decides what applies to you.

What should you keep for governance and third parties?

Section 3.1 gives senior management duties, including setting the technology risk framework, keeping policies and standards effective, defining staff roles, and informing the board of major developments. A footnote suggests a RACI matrix as one way to track roles.

Section 3.2 asks for policies, standards and procedures that are reviewed regularly. Deviations must be risk assessed with senior management approval and reviewed periodically (3.2.2). Evidence: the policy set with review dates, a deviation register with approvals and expiry dates, and compliance check results (3.2.3).

Section 3.3 asks for an inventory of information assets. Keep the inventory and its update history.

Section 3.4 covers third parties. Assess the technology risks before contracting (3.4.2) and ensure ongoing care and diligence (3.4.3). Evidence: pre-contract assessments, vendor reviews on a schedule, and incident records involving vendors.

What should you keep for software development?

Section 6.1 is the heart of it for engineers:

• 6.1.2: secure coding and source code review standards covering input validation, output encoding, access controls, authentication, cryptographic practices and error handling.
• 6.1.3: a policy for third party and open-source code, reviewed and tested before integration.
• 6.1.4: tracking of updates and reported vulnerabilities in that code.
• 6.1.5: developer training.
• 6.1.6: an application security validation strategy, which may mix static, dynamic and interactive testing.
• 6.1.7: tracking of all issues found, with major issues fixed before production deployment.

Constructed example. A bank's payments team keeps a dependency inventory generated at build time, a pull request gate that blocks merges with unresolved high-severity findings, and a ticket for every waiver with an approver and expiry. Those three artifacts answer 6.1.3, 6.1.4 and 6.1.7 in one walkthrough.

What should you keep for patching and testing?

Section 7.4.1 asks for a patch process with timeframes commensurate with the criticality of the patch and the system. 7.4.2 asks that patches be tested before production. Keep the written timeframes, the test record and a log of patches applied against due dates.

Section 13.1 covers vulnerability assessment: regular, with frequency set by system criticality, covering vulnerability discovery, weak configurations, open ports and application vulnerabilities, plus common web checks for web systems. Section 13.2 covers penetration testing, with internet-facing systems expected to be tested at least once a year or after major changes (13.2.4). Section 13.6 asks for remediation tracking, severity classification and defined fix timeframes.

What to do

1. Map each section above to an owner, a document and a record source.
2. Write down timeframes for patches and vulnerability fixes by severity.
3. Generate a dependency inventory on every build and store it.
4. Keep a deviation register with approver, risk assessment and review date.
5. Store scan, test and pen test reports with remediation tickets linked.
6. Schedule vendor reviews and keep the outputs.
7. Run a tabletop review where someone asks for the evidence cold, section by section.

Safeguard's compliance automation can collect and organise some of these records, and it explains the framework rather than certifying you.

Quick check

Sources

• MAS Technology Risk Management Guidelines, January 2021 (PDF)

Last reviewed: 18 October 2026.