Singapore MTCS SS 584 Multi-Tier Cloud Security Guide

A cloud provider's certificate only helps a buyer if the buyer knows what level it certifies, what is in scope and what the provider has disclosed, and Singapore's Multi-Tier Cloud Security standard was built to make that explicit. MTCS, published as Singapore Standard SS 584, defines three tiers of cloud security and an accredited certification scheme run by the Infocomm Media Development Authority (IMDA), with each certified provider filing a self-disclosure form. This guide explains what SS 584 is and who uses it, how the tiers and certification process work, how to read a provider's certificate and disclosure, where machine identities fit, and how MTCS relates to ISO/IEC 27001, CSA STAR and other cloud schemes. It is written for cloud service providers seeking certification, and for security, procurement and risk teams in Singapore and the region buying cloud services.

Key takeaways

Three levels, chosen by risk. Level 1 is a basic baseline for non-critical uses, Level 2 adds governance and tenancy controls for most business use, and Level 3 adds reliability and resiliency controls for regulated and high-impact systems.
The current edition is SS 584:2020. The standard was first published on 13 November 2013 and its second revision in October 2020; IMDA's certification pages reference SS 584:2020.
Certification is accredited and time-limited. IMDA states certificates are valid for three years with a yearly surveillance audit, must come from accredited certification bodies, and only accredited certificates are listed.
The self-disclosure form is the buyer's best document. Each listed provider files an MTCS self-disclosure form covering service-level information such as data retention, sovereignty, portability, availability and incident management.
A certificate covers listed services and sites only. Major providers hold Level 3 for a subset of services; customers still own their identities, configuration and data in every tier.

What it is and who it applies to

SS 584, "Specification for multi-tiered cloud computing security", was developed under Singapore's Information Technology Standards Committee (ITSC). IMDA describes it as the world's first cloud security standard covering multiple tiers of cloud security. Work began in April 2012 under an ITSC working group led by the then Infocomm Development Authority (IDA), the standard launched on 13 November 2013, an accredited certification scheme followed in 2014, and the second revision was published in October 2020. Amazon Web Services and Microsoft both describe the standard as building on the ISO/IEC 27001 information security management system model, and Microsoft's documentation describes the standard as containing 535 controls across the three levels. The full standard is sold through the Singapore Standards eShop; this guide relies on IMDA's public pages and provider documentation and does not reproduce clause numbering.

Date	Milestone (source)
April 2012	ITSC working group starts work (IMDA press release, 2013)
13 November 2013	MTCS SS 584 launched (IMDA press release; AWS)
2014	Accredited MTCS certification scheme introduced (IMDA)
October 2020	Second revision published, SS 584:2020 (AWS; IMDA pages reference SS 584:2020)

Cloud service providers: IaaS, PaaS and SaaS providers serving Singapore customers certify services at a chosen level. IMDA's list showed 47 certified service entries (22 IaaS, 10 PaaS and 15 SaaS) when checked on 27 October 2026.
Public sector buyers: Microsoft states that Level 3 is required for certain cloud solution implementations by the Singapore government. Confirm the current requirement with the buying agency's own policy.
Regulated organisations: Level 3 is designed for regulated organisations and high-impact systems. Financial institutions should read it alongside the MAS Technology Risk Management Guide.
Regional regulators: AWS reports that Korea's financial security regulator reviewed MTCS and recognised Level 3 certification for Korean financial customers, removing the need to separately validate 109 controls from its guideline.

Structure and key requirements

The three levels

Level	Description (Microsoft Learn summary of the standard)	Typical uses	Buyer question
Level 1	Basic security: low cost, minimum set of baseline controls	Website hosting, test and development, simulation, non-critical business applications	Is any sensitive or personal data going here? If yes, Level 1 is probably not enough.
Level 2	More stringent governance and tenancy controls addressing data security risks and threats	Most organisations and most cloud usage, including mission-critical business applications	Does the disclosure describe tenant separation and data handling you can accept?
Level 3	Adds reliability and resiliency controls on top of Levels 1 and 2	Regulated organisations, high-impact systems, sensitive information	Are the specific services and data centre sites you will use inside the Level 3 scope?

Self-disclosure

From its launch IMDA required certified providers to self-disclose service-oriented information normally found in service level agreements. The 2013 announcement lists the areas below, which remain the most useful starting point for due diligence.

Disclosure area	What to look for	Why it matters
Data retention	Retention periods, deletion on exit, backup retention	Determines what remains after contract end
Data sovereignty	Locations of storage and processing, support access locations	Legal and regulatory exposure. See the Data Sovereignty and Residency Guide.
Data portability	Export formats and timelines	Exit and concentration risk
Liability	Limits and exclusions	Residual risk the customer carries
Availability	Committed service levels and how they are measured	Matches business continuity needs
Business continuity and disaster recovery	Recovery objectives, site diversity, testing	Resilience of the service
Incident and problem management	Notification timelines, contacts, post-incident reporting	Feeds your own incident plan

Certification process

Scope: the provider decides which services, sites and level to certify.
Prepare documents: a Statement on Applicability and Compensating Controls, and the MTCS CSP Self-Disclosure form.
Audit: an accredited certification body assesses the provider against SS 584 at the chosen level.
Certificate: valid for three years, with a yearly surveillance audit.
Listing: the provider sends the accredited certificate and completed disclosure form to IMDA ([email protected]) for listing; only accredited certificates are listed.

Identity and NHI requirements

SS 584's clause-level identity requirements are not public, so treat this section as the questions a certified provider and its customers should be able to answer, framed against the levels above. In cloud services the identities that matter most are non-human: provider automation accounts with access to tenant infrastructure, customer API keys and service accounts, workload identities, signing keys and the keys in the provider's key management service.

Area	Provider side (in certification scope)	Customer side (never covered by the provider's certificate)
Administrative access	How operator and automation access to tenant environments is authorised, logged and reviewed	Who holds tenant administrator roles, protected with phishing-resistant MFA
Machine credentials	Rotation and storage of internal service credentials and signing keys	API keys, access keys and service account keys issued in your tenancy. See the Cloud Workload Identity Guide.
Tenancy	Separation between tenants, a core Level 2 concern	Separation between your own environments (production, test)
Key management	Protection of key management services and HSMs	Key policies, who can use and administer customer keys
Logging	Provider-side audit logs, and what is shared with customers	Turning on and retaining tenant audit logs; alerting on new keys and roles

Use the Cloud IAM Review Checklist for the customer side and the Shared Responsibility Models Guide to agree the split before contract signature.

Implementation steps

For a cloud service provider seeking certification

Buy SS 584:2020 and choose the level. Pick the level your target customers need; Level 3 for public sector and regulated customers.
Build on your ISMS. If you already hold ISO/IEC 27001, use IMDA's ISO/IEC 27001 to MTCS cross-certification document to identify additional requirements.
Set the scope precisely. List services, regions and data centre sites; customers will compare this list with what they buy.
Write the Statement on Applicability and Compensating Controls. Justify any control not applied and the compensating measures in place.
Complete the self-disclosure form honestly. It becomes a public procurement document and a contractual expectation.
Run a readiness assessment against the chosen level, fix gaps, then engage an accredited certification body.
Plan the surveillance cycle. Annual surveillance audits and a three-year recertification; scope changes need to go through the certification body.

For a cloud customer

Classify the workload and decide the minimum level you require.
Check the IMDA listing for the exact service and level, and download the certificate and self-disclosure form.
Compare scope with your deployment: services, regions, sites and certificate validity dates.
Read the disclosure against your requirements for retention, sovereignty, availability and incident notification, and write gaps into the contract.
Configure your own side: identities, keys, logging and network controls, which no provider certificate covers.
Diarise the certificate expiry and request the new certificate after each surveillance or recertification audit.

Decision guidance

MTCS or ISO/IEC 27001 alone: ISO/IEC 27001 shows a management system; MTCS adds a cloud-specific, tiered control set and a standard disclosure. For Singapore public sector or regulated buyers, MTCS is the more specific signal.
MTCS or CSA STAR: CSA STAR is widely recognised internationally; IMDA publishes cross-certification documents in both directions, so providers serving both markets can reduce duplicate work. See the CSA STAR for AI and AI-CAIQ Guide.
Small SaaS provider: Level 1 or 2 may be proportionate if customers are not regulated; be clear in sales material which level you hold.
Multi-region provider: certify the regions Singapore customers use; AWS, for example, extended its scope to additional regions over time.

Evidence and assessment

Evidence	Who holds it	Check or metric
Accredited MTCS certificate	Provider, listed by IMDA	Level, scope, sites and expiry date match the contract
Self-disclosure form	Provider, listed by IMDA	Every disclosure area reviewed and accepted or contracted around
Statement on Applicability and Compensating Controls	Provider; request under NDA	Excluded controls that affect your workload
Surveillance audit outcomes	Provider and certification body	Major non-conformities and their closure
Customer configuration evidence	Customer	Cloud posture scores, identities with administrative rights, keys older than policy

Reading an MTCS certificate

Certificates published through the IMDA listing follow the usual management system certificate format. When you open one, check each of these fields rather than the logo alone:

Standard and edition: the certificate should name SS 584:2020; an older edition suggests the provider has not recertified.
Level: Level 1, 2 or 3, stated explicitly.
Scope: the named services (sometimes dozens of them) and the service model (IaaS, PaaS or SaaS). If your service is not named, it is not certified.
Sites: offices and data centres covered; compare with the region you deploy into.
Dates: initial certification date, current validity start and expiry. A three-year validity window is normal under the scheme.
Certification body and number: confirm the body is accredited and, where offered, validate the certificate online with the issuer.

Useful programme measures for a customer: the percentage of cloud services in use with a current MTCS (or equivalent) certificate at the required level, the number of services where scope does not cover the region used, days until the next certificate expiry, and the number of disclosure gaps without a contractual remedy.

Mapping to other frameworks

Framework	Relationship to MTCS
ISO/IEC 27001	MTCS builds on the ISO/IEC 27001 ISMS model; IMDA publishes cross-certification documents for ISO/IEC 27001:2013 in both directions. See the ISO 27001 Certification Guide.
ISO/IEC 27017 and 27018	Cloud control and cloud PII codes of practice; IMDA publishes a harmonisation document between MTCS and ISO/IEC 27018:2014. See the ISO/IEC 27017 Cloud Security Controls Guide.
CSA STAR	Cross-certification documents from MTCS to CSA STAR and back
IMDA TR 62:2018	Guidelines for cloud outage incident response; complements Level 3 resiliency expectations
Germany BSI C5, Australia IRAP, US FedRAMP	Comparable national cloud assurance schemes with different methods. See the Germany BSI C5 Guide and the Australia IRAP Guide.
NIST CSF 2.0	GV.SC-06 (due diligence before supplier relationships), ID.RA-10 (critical suppliers assessed before acquisition), GV.SC-05 (requirements in contracts)

Common pitfalls

Accepting "MTCS certified" without a level: a Level 1 certificate says little about controls needed for regulated data.
Ignoring scope: providers certify subsets of services and sites; the service you buy may not be in scope.
Expired certificates: three-year validity and annual surveillance mean certificates must be rechecked, not filed once.
Not reading the self-disclosure form: it is short, public and often contains the retention or location detail that matters most.
Assuming the provider's certificate covers your tenancy: misused customer keys and over-privileged service accounts are outside any provider certificate.
Using unaccredited certificates: IMDA lists only accredited certificates; other documents may not have been issued under the scheme, so verify the issuer and the listing before relying on one in a procurement decision.
Treating MTCS as an outage guarantee: Level 3 adds reliability and resiliency controls, but availability commitments still come from the contract and disclosure, and your own continuity plan must cover provider outages.

Practitioner checklist

Set a minimum MTCS level per data classification in your cloud policy.
Verify each provider service on the IMDA listing at the required level.
Download and review the certificate and self-disclosure form for every in-scope service.
Match certificate scope (services, regions, sites) against your actual deployment.
Record certificate expiry dates and recheck after each surveillance audit.
Write disclosure gaps (retention, sovereignty, notification) into contract terms.
Review your own tenancy identities, keys and logging; no certificate covers them.
Providers: use IMDA's cross-certification documents to reuse ISO/IEC 27001 and CSA STAR evidence.

Singapore MTCS SS 584 Guide: Cloud Security Tiers, Certification and Evidence