IT Audit vs BCM Audit: What Singapore Financial Institutions Need to Know for 2027

For Singapore financial institutions, the next MAS BCM audit cycle is already on the horizon.Most Singapore financial institutions completed their first Business Continuity Management (BCM) audit under the Monetary Authority of Singapore’s 2022 Guidelines. The first cycle was due by June 2024. The next cycle falls due by June 2027.

The key question is whether institutions are preparing for the next MAS BCM audit as a genuine business resilience assessment — or simply treating it as an extension of their IT audit.

That distinction matters.

An IT audit asks whether systems, infrastructure and data can be recovered. A BCM audit asks a broader question: can the institution continue delivering critical services to customers when a serious disruption occurs?

For FIs approaching the second BCM audit cycle, the gap between technical recovery and actual business resilience deserves renewed attention.

This article explains the difference between IT audit and BCM audit, the MAS expectations that connect the two, common implementation gaps, and practical steps institutions can take before the 2027 audit cycle.

Executive Summary

Most Singapore FIs have already experienced their first BCM audit cycle. The next major milestone is the second cycle due by June 2027.

The distinction between an IT audit and a MAS BCM audit is fundamental:

• IT audit focuses primarily on technology controls, systems, infrastructure and recovery.
• BCM audit assesses whether critical business services can continue or recover following severe disruption.
• BCM considers dependencies across people, processes, technology and data, facilities, and third parties.
• Successful disaster recovery does not automatically demonstrate business continuity.
• SRTOs should reflect business service requirements rather than simply inherited IT recovery targets.
• Third-party dependencies and concentration risks require practical testing, not only documentation.
• Lessons from incidents and previous audit findings should feed directly into BCM testing and remediation.

The most important preparation question is therefore not simply:

“Can our systems recover?”

It is:

“Can we continue serving customers when multiple dependencies fail at the same time?”

1. MAS BCM Audit vs IT Audit: The Basic Distinction

The two audits are closely related, but they answer different questions.

An IT audit primarily examines whether systems, technology controls, infrastructure and data are appropriately protected and recoverable.

A MAS BCM audit takes a broader business-service perspective. It considers whether the institution can maintain or restore critical business services when technology, people, facilities or third parties are disrupted.

2. MAS BCM Audit: The Regulatory Framework

MAS Guidelines on Business Continuity Management (June 2022) replaced the older 2003 guidelines and shifted the whole conversation from “can IT recover the server” to “can the FI keep serving customers.” FIs had to align with the new guidelines by June 2023, complete a first comprehensive BCM audit by June 2024, and the framework runs on a three-year audit cycle from there. The guidelines require FIs to map dependencies across five pillars — people, processes, technology/data, facilities, and third parties — and to set SRTOs that reflect realistic business impact, not just a target someone wrote down.

MAS Technology Risk Management (TRM) Guidelines, last substantially revised in 2021, sit alongside binding notices — the Cyber Hygiene Notice (Notice 655) and system-availability notices that, for critical systems, generally expect unscheduled downtime to stay within a few hours in any 12-month period. These are enforced with real teeth: MAS has pursued well over a hundred enforcement actions and multi-million-dollar penalties tied to technology-related failures in recent years, underscoring that this isn’t a paperwork exercise.

3. How IT Audit and MAS BCM Audit Work Together

The two audits aren’t competing — they’re sequential layers of the same resilience story:

• IT audit confirms the mechanics: the database cluster fails over, the backup site comes online, the recovery time target is met on paper.
• BCM audit tests whether that technical recovery translates into an actual customer outcome: can operations staff process transactions on the restored system if the office is closed and a third-party payment gateway is also down?

In practice, BCM auditors use IT DR test results as evidence, not as a conclusion. A technically successful DR test can still be flagged as insufficient by a BCM auditor if it didn’t account for the manual workarounds staff would need mid-crisis, or if it ignored a vendor dependency that sits outside IT’s control.

4. Common MAS BCM Audit Readiness Gaps

Most existing content on this topic stops at “here are the two frameworks.” What’s missing — and what actually determines whether an FI passes its next MAS review cleanly — is where implementation breaks down in practice.

1. BCM Audits That Look Like IT DR Audits

Many FIs still scope and staff their BCM audits primarily through IT audit teams. The testing often focuses on system failover, backup restoration and disaster recovery.

That testing is important, but it does not cover the full BCM requirement.

A BCM audit should also examine whether the institution can continue delivering critical business services when people, processes, facilities or third parties are disrupted.

MAS expects BCM auditors to have appropriate BCM and operational resilience expertise. This is distinct from general IT audit qualifications such as CISA.

Where this competency gap exists, an audit may validate technology recovery while leaving the people-and-process side untested.

Key question: Who actually processes the customer transaction when the primary system is unavailable, and how does the process continue?

2. Third-Party and Concentration Risk

Many institutions maintain dependency maps that identify vendors, cloud providers and other critical third parties.

However, documenting a dependency does not demonstrate that the dependency has been tested.

Consider a scenario where a critical outsourced provider becomes unavailable while an internal system also fails. The institution may discover that its recovery plan depends on a service it can no longer access.

Concentration risk can create a similar problem. Several critical functions may depend on the same data centre, technology provider or specialist team.

Practical focus: Test critical third-party dependencies under realistic disruption scenarios rather than relying only on documented vendor assessments.

3. SRTOs That Are Not Evidence-Based

Service Recovery Time Objectives (SRTOs) should reflect what the business can realistically tolerate and deliver.

They should not simply carry forward an old disaster recovery target.

An FI should review its SRTOs against a current Business Impact Analysis at the critical business service level.

This helps determine whether the recovery target reflects actual business requirements, customer impact and operational dependencies.

If an SRTO is unrealistic, the audit may end up testing the institution against a target that was never achievable in practice.

Practical focus: Revalidate SRTOs using current business impact analysis, service dependencies and recovery capabilities.

4. Testing That Avoids Severe but Plausible Scenarios

Routine exercises can create a false sense of readiness.

Teams may know the scenario in advance, understand their roles and follow a familiar recovery sequence.

Real incidents rarely happen that way.

MAS expects institutions to consider severe but plausible scenarios. Testing should therefore challenge the organization beyond a predictable system outage.

For example, an institution could test a scenario involving multiple simultaneous failures, such as:

• A primary site becoming unavailable
• A critical technology provider experiencing an outage
• Key personnel being unavailable
• Manual processing becoming necessary

Practical focus: Test combinations of failures that could realistically affect the delivery of a critical business service.

5. Board and Senior Management Oversight That Stops at Reporting

The Board and senior management have an important role in overseeing BCM risks and remediation.

However, receiving a BCM dashboard or audit summary is not the same as actively managing resilience risks.

Management should have clear visibility of:

• Outstanding BCM audit findings
• Repeated testing failures
• Critical dependency risks
• Third-party concentration
• Unrealistic recovery targets
• Delayed remediation actions

The first BCM audit cycle was due by June 2024, while the next cycle falls due by June 2027. Institutions should therefore avoid carrying unresolved findings into the next audit cycle.

Practical focus: Track remediation to closure and give material BCM risks appropriate Board-level visibility.

6. Weak Link Between Incident Reporting and BCM Learning

Incident reporting can provide valuable information for improving BCM preparedness.

However, institutions do not always feed lessons from operational incidents back into their BCM scenario libraries and threat monitoring processes.

This can result in organizations continuing to test yesterday’s risks while new disruption patterns emerge.

Incident analysis should therefore inform future BCM scenarios, testing priorities and dependency reviews.

Practical focus: Create a formal feedback loop between technology incidents, operational incidents, BCM testing and resilience improvements.

 

5. Preparing for the Next MAS BCM Audit

• Staff BCM audits with BCM-specific expertise, not just IT auditors re-labelled for the exercise.
• Re-derive SRTOs from a current, service-level Business Impact Analysis — don’t inherit old DR targets.
• Extend dependency mapping to third parties and test it, not just document it — simulate a vendor outage alongside an internal failure.
• Run at least one “severe but plausible” scenario a year that assumes multiple simultaneous failures (e.g., site + vendor + key personnel unavailable).
• Close the loop between IT DR evidence and BCM audit conclusions — require the BCM audit to explicitly assess whether technical recovery produces a usable customer outcome.
• Track remediation items from the prior BCM audit cycle to closure before the next one starts, with Board-level visibility, not just IT-level visibility.
• Align technology risk governance (TRM) and BCM under one resilience narrative for MAS reporting, rather than running them as separate compliance tracks that only meet at audit time.

6. The Bottom Line

IT audit and BCM audit answer different questions, and MAS has been explicit that meeting one doesn’t satisfy the other. For Singapore FIs heading toward their second BCM audit cycle, the compliance risk isn’t a lack of awareness of the guidelines — it’s the gap between a technically compliant IT recovery and a genuinely resilient business service. Closing that gap means treating BCM audit as its own discipline, staffed and tested accordingly, with IT audit feeding into it as one input among several — not standing in for it.

How Pecuniya Can Help

A strong BCM programme requires more than policies and annual testing.

It requires the ability to demonstrate that critical business services can withstand disruption and recover within defined expectations.

Pecuniya supports regulated financial institutions with practical compliance, risk management, audit and governance solutions.

Our Risk Management services include risk assessment, internal audits, framework design and governance advisory.

We also support organisations with business continuity plans and internal control documentation as part of broader compliance framework development.

For institutions preparing for the next BCM audit cycle, a focused readiness assessment can help identify gaps before they become audit findings.