A cloud computing company is reliable when customers understand what it provides, what remains their responsibility and how essential services recover after disruption. A virtual machine showing ‘running’, a high uptime percentage or a certification logo does not prove a customer’s entire application works. Clear contracts, accountable security, accurate metering, meaningful backups and tested recovery are the measures that matter.
This guide follows CedarCloud Platform, a wholly fictional Singapore managed application-platform provider. Its customer, FernLedger, runs a small business invoicing service using CedarCloud’s managed database and identity gateway. During planned maintenance, the database remains available but the gateway fails for 75 minutes; customers cannot log in and issue invoices. A status dashboard reports green for the database, so the cloud company and its customer initially disagree about what was affected. No real cloud service or outage is described.
The Gold Standard master hub is about management and systems execution. Related eduKate guides address Cloud Computing as a service model, Data Centre Companies as physical infrastructure operators and Software Companies as application builders. Here the subject is the cloud provider as a company, accountable for its contracted platform, tenant protection, cost, incident response and customer continuity.
Find the cloud-company decision you need
Follow the fictional hosted invoicing service through platform responsibility, certification, privacy, an identity-gateway outage and verified recovery.
Chapter index
Service boundaries, certification and data governance · Chapters 1–5
Architecture, backup and true resilience · Chapters 6–10
- Separate voluntary resilience guidance from binding legal requirements
- Protect tenant isolation as a product boundary
- Understand the PDPA responsibilities of a cloud data intermediary
- Make data residency and international processing transparent
- Plan availability across realistic dependencies and failure domains
Change, incident management and customer cost · Chapters 11–15
Accountability, exit and measured recovery · Chapters 16–20
- Explain metered cloud costs before a bill becomes a surprise
- Test customer support across platform and application boundaries
- Prepare a secure, workable migration and exit
- Use downtime arithmetic without claiming the customer was unaffected
- The gold standard is a provider that restores what it actually promised
1. Identify the actual service layer being sold
Infrastructure-as-a-Service supplies configurable compute, storage and networking; Platform-as-a-Service offers managed development and runtime components; Software-as-a-Service supplies applications used more directly by customers. Real contracts can combine all three. A provider should not claim it manages a customer’s application simply because it hosts one supporting database.
CedarCloud provides a managed database and identity gateway. FernLedger writes and operates its invoicing application. The firms need a responsibility map for service availability, customer software, user access, data protection and incident response. When invoices cannot be created, teams must be able to tell which components were affected without dismissing the customer’s outcome as irrelevant.
Back to chapter index · Next chapter
2. Define the customer’s essential tasks before publishing an SLA
Cloud service-level agreements often state availability for named components. Customers, however, buy infrastructure to enable actual business workflows such as submitting orders, processing patient bookings or issuing invoices. Component SLAs are useful when their scope is clear but misleading if sold as guarantees of complete business outcomes.
CedarCloud explains that database availability and identity gateway availability are measured separately under the applicable contract. It identifies monitoring that can verify both. FernLedger understands what it must test at the application level. A promise of ‘99.9% service uptime’ needs the precise service name, time window, exclusions and measurement method before it becomes meaningful.
Back to chapter index · Next chapter
3. Avoid treating a data centre and a cloud platform as the same business
A data centre owns or manages space, electrical supply, cooling and physical access; a cloud service can add virtualisation, access management, managed databases, application interfaces, billing and monitoring. One company can operate both, but the risks and customer promises are not interchangeable.
The Data Centre Companies guide covers physical dependencies. CedarCloud’s database can remain reachable inside a healthy facility while its gateway software prevents end users from signing in. The cloud company needs its own software and operational controls as well as evidence about physical infrastructure. ‘The racks have power’ does not complete an invoice.
Back to chapter index · Next chapter
4. Map the shared-responsibility boundary for security
A cloud provider may secure its physical and platform infrastructure while customers control identities, application code, content, selected configurations and access policies. The exact split depends on the service. A generic sentence saying ‘security is shared’ leaves room for dangerous assumptions.
CedarCloud maintains a plain-language responsibility table naming who manages platform patches, customer roles, encryption configuration, vulnerability reporting and data recovery under its actual service. It warns customers about responsibilities they retain without treating a poorly explained contract as sufficient communication. When a security issue emerges, both parties need authorised contacts and a workable escalation path.
Back to chapter index · Next chapter
5. Use Singapore’s MTCS certification with its true scope
Singapore’s Multi-Tier Cloud Security standard SS 584:2020 defines three tiers for cloud service assurance. A certificate is linked to a specific provider and service scope, with its own certification status. It does not guarantee that every platform feature, application or business workflow is flawless.
IMDA’s Cloud Computing and Services guidance explains the MTCS standard. Its certification page describes an accredited process, three-year certification and annual surveillance audits. CedarCloud should identify the exact certified service and tier before making marketing claims, not imply its customers’ own applications inherit blanket certification.
Back to chapter index · Next chapter
6. Separate voluntary resilience guidance from binding legal requirements
Singapore’s 2025 Advisory Guidelines for the Resilience and Security of Cloud Services and Data Centres recommend industry practices to reduce disruptions. These are important but not equivalent to a universal statutory operating licence for every cloud service. Sector-specific rules may apply to customers or particular regulated service providers.
IMDA’s advisory guidelines reference MTCS, Cloud Security Alliance controls, ISO 27001 and ISO 22301. CedarCloud decides which recommendations to adopt, assigns responsible personnel and tests whether controls work. It must not advertise voluntary adherence as approval by IMDA, nor conclude that voluntary guidance removes duties imposed by separate laws or customer contracts.
Back to chapter index · Next chapter
7. Protect tenant isolation as a product boundary
Cloud platforms may host several organisations on shared infrastructure. Tenant isolation helps ensure one customer’s workloads and data remain separate from another’s according to the contracted model. Errors in software, access policies or support tools can violate those boundaries even when the underlying servers are functioning.
CedarCloud reviews how its managed service distinguishes customer identities, administrator privileges, backups and data access. Support personnel should not browse another tenant’s records to debug a routine ticket. Qualified security specialists need tested assurance appropriate to architecture, while management keeps a process for investigating suspected cross-tenant information exposure.
Back to chapter index · Next chapter
8. Understand the PDPA responsibilities of a cloud data intermediary
A cloud provider processing personal data on behalf of and for another organisation under a written contract may qualify as a data intermediary under Singapore’s Personal Data Protection Act. The relevant responsibilities differ between the customer organisation and the intermediary. A cloud contract does not simply transfer all legal privacy obligations from customer to provider.
PDPC organisational guidance and its cloud-services advisory explain intermediary protection, retention and breach-notification duties. CedarCloud determines which data it processes for clients and which data it collects for its own purposes. Both require lawful, clearly allocated governance rather than a blanket claim that ‘the customer owns privacy’.
Back to chapter index · Next chapter
9. Make data residency and international processing transparent
A cloud company may offer a Singapore region while some operations use a remote support desk, global monitoring system or cross-border backup arrangements. Customers need the actual geographical and legal facts that matter to their data and contractual constraints. A marketing claim that data never leaves Singapore should be supported across every relevant processing activity.
CedarCloud documents available regions, customer choices and cross-border access or transfer arrangements to the extent required by law and contract. FernLedger should know whether remote support can access personal data and what contractual restrictions apply. Managers must not use the physical location of one server rack as proof that every service, log, administrator and backup remains inside the same national boundary.
Back to chapter index · Next chapter
10. Plan availability across realistic dependencies and failure domains
Cloud services may use multiple instances, network connections, availability zones or regions. These may improve resilience but can still share some control-plane, identity, software or operational dependencies. A second copy in the same failing system is not necessarily an independent recovery capability.
CedarCloud discovers that its identity gateway and database have different failure paths. Management asks whether the architecture could tolerate a gateway outage, which failover options are authorised and how customers are informed. A label saying ‘multi-zone’ does not establish all service components are independent. Resilience promises need evidence appropriate to the precise architecture.
Back to chapter index · Next chapter
11. Protect backups and know what restoration actually includes
Snapshots, database backups and replicated data serve different purposes. A stored copy may be corrupt, incomplete or inaccessible during the incident that makes it necessary. The provider needs versioned policies, appropriate protection and practical recovery tests under its service agreements.
CedarCloud tests whether a chosen backup can support an authorised restore of the managed database in a controlled environment, then reports what was verified and what was not. FernLedger remains responsible for any backup or recovery tasks the contract leaves with it. A successful backup job alone is not proof of usable invoices after an identity gateway failure.
Back to chapter index · Next chapter
12. Translate RPO and RTO into tested service expectations
Recovery Point Objective concerns an acceptable data-loss window, while Recovery Time Objective concerns how long a recovery process is planned to take. Both must be defined for the relevant service and scenario. A service offering one objective on paper cannot guarantee every possible incident will meet it without appropriate evidence.
CedarCloud explains which recovery objectives are contracted and which belong to FernLedger’s application. Exercises should reveal whether critical steps depend on unavailable administrators, external identity providers or lengthy manual decisions. The company reports results and limitations honestly. A test of the database alone does not establish restoration of the complete user login and invoicing journey.
Back to chapter index · Next chapter
13. Maintain observability that reflects customer impact
Cloud monitoring can track CPU use, request errors, database connectivity and service-component status. Those signals may not reveal whether an end user can complete a critical task. The provider needs appropriate synthetic or other customer-relevant checks within the actual supported boundaries.
During CedarCloud’s incident, the database dashboard is green while login attempts fail. Its operations team should recognise that the contracted identity gateway is also part of customer service and escalate accordingly. A useful incident timeline separates observed facts from hypotheses and identifies which customers and components may be affected. Customers deserve an explanation they can use, not a screenshot of a healthy unrelated metric.
Back to chapter index · Next chapter
14. Control changes across platform and customer dependencies
Cloud services change through patches, API versions, certificate renewals, configuration updates and infrastructure maintenance. A change may succeed in one subsystem but break compatibility elsewhere. Providers need appropriate testing, authorisation and a practical way to respond if a release causes unexpected impact.
CedarCloud’s maintenance procedure reviews gateway and database dependencies, customer-facing change notices and any version-specific limitations. FernLedger should know when it must update its own integrations. Engineers preserve change records and avoid improvising potentially destructive actions during an incident. Management’s role is to make controlled correction possible under pressure.
Back to chapter index · Next chapter
15. Treat security events and ordinary outages differently
A cloud outage may arise from a software failure, misconfiguration, power issue or security incident. These possibilities have different evidence, notification and recovery needs. Declaring a cyberattack without support can mislead customers, while dismissing a possible breach solely as downtime can delay appropriate protective action.
CedarCloud routes suspected security events to competent investigators, maintains relevant evidence and follows duties that apply to its own service and customers. The Cybersecurity Companies guide describes authorised investigations and recoverable incidents. Its helpdesk distinguishes verified observations from technical speculation until a responsible reviewer establishes the facts.
Back to chapter index · Next chapter
16. Explain metered cloud costs before a bill becomes a surprise
Cloud invoices may depend on compute time, storage, network transfers, managed service requests or reserved capacity. A free trial or introductory credit can end while workloads continue. Customers need to understand billing units, price changes, budget alerts, account suspension conditions and how disputes are handled.
CedarCloud supplies usage detail that connects service identifiers, quantities, rates and the billing period. FernLedger can inspect whether a data-transfer spike reflects legitimate customer work, a test or an error. The provider should not respond to a disputed charge with an unexplained total. Its own revenue model also needs realistic infrastructure and support costs, rather than assuming every customer will consume only a minimum allowance.
Back to chapter index · Next chapter
17. Test customer support across platform and application boundaries
A cloud support team can close a ticket by proving that a server runs, while the customer is still unable to log in or reconcile an invoice. The service provider needs an honest way to determine whether the failure lies inside its agreed scope and to provide useful evidence when it does not.
CedarCloud and FernLedger use a shared case record that identifies the affected gateway, database and application tests. The cloud provider owns correction of its gateway where appropriate; FernLedger owns its application logic. Neither should pass the customer endlessly between helpdesks. A defensible support answer states what was observed, what was changed and whether the original issue is still reproducible.
Back to chapter index · Next chapter
18. Prepare a secure, workable migration and exit
Cloud businesses can create substantial switching costs through data formats, APIs, billing models and proprietary managed services. Customers need accurate information about data export, contract end, access revocation and applicable retention or deletion. A platform should not make basic departure requirements practically impossible without clear prior disclosure.
CedarCloud documents how FernLedger can obtain its relevant data, transfer supported configurations and close its account under agreed terms. The company retains or deletes personal information according to its actual legal obligations, not a blanket sales slogan about instant erasure. A credible exit process reduces vendor lock-in risks and encourages customers to trust the service while they use it.
Back to chapter index · Next chapter
19. Use downtime arithmetic without claiming the customer was unaffected
A cloud provider’s availability indicator should identify the relevant time interval and component. If a service remained unavailable for a number of minutes, a simple uptime percentage can help, but it is neither a complete account of user harm nor proof of SLA compliance. The precise contract may measure differently.
Fictional calculation: a 30-day period contains 43,200 minutes. If the managed identity gateway is unavailable for 75 minutes, its simple observed availability is (43,200 − 75) ÷ 43,200, about 99.83%. The database may simultaneously report 100% availability under its own measure, but customers still could not log in. These invented figures are not a cloud-industry benchmark or a contractual service-credit determination.
Back to chapter index · Next chapter
20. The gold standard is a provider that restores what it actually promised
CedarCloud’s fictional gateway incident is only resolved when engineers understand why maintenance affected authentication, the contracted component is repaired, necessary records are preserved and customers receive a reliable explanation of the impact. The company then tests whether the fix works across ordinary access and failure scenarios.
A gold-standard cloud computing company describes its boundaries plainly, protects tenant data, earns the certifications it actually claims, makes costs transparent and proves recovery when a service fails. Its value is not a high dashboard number in isolation. It is a platform customers can depend on, understand and leave responsibly when their needs change.
Worked uptime example: the database was online but the customer was offline
These are fictional values for explaining service boundaries, not a contractual uptime audit or an official MTCS assessment.
| Defined service and measure | Illustrative observation | Conclusion |
|---|---|---|
| Reporting window | 30 days = 43,200 minutes | Explicit denominator |
| Managed identity gateway downtime | 75 minutes | Customer login was disrupted |
| Gateway simple availability | 43,125 ÷ 43,200 ≈ 99.83% | Not a complete customer SLA determination |
| Database availability | Illustratively 100% | Does not mean the customer application was usable |
| Actual invoicing outcome | Users unable to authenticate | Needs an application-level and responsible service explanation |
Cloud company and business-customer audit
- Can the provider distinguish IaaS, PaaS, SaaS and the actual contracted features?
- Does the shared-responsibility statement identify security and recovery owners?
- Does any MTCS certificate accurately describe the specific certified service and tier?
- Are IMDA’s 2025 advisory guidelines identified as guidance rather than automatic licensing?
- Does the company understand when it is a PDPA data intermediary and what it must protect?
- Are data residency, remote support and cross-border backups described truthfully?
- Can independent failure dependencies and disaster recovery be demonstrated under realistic tests?
- Are outage metrics and service credits tied to the correctly named components?
- Can customers inspect actual usage charges, exports and account-closure rights?
- Does a support ticket stay open when the customer’s contracted cloud component remains unavailable?
Verified official guidance and eduKate ecosystem links
- IMDA: Cloud Computing and Services — MTCS SS 584:2020 and outage guidance
- IMDA: MTCS Certification and Compliance — accredited scopes and surveillance
- IMDA: Cloud Services and Data Centre Resilience Advisory Guidelines (2025) — recommended industry practices
- PDPC: Organisation Data Protection Guidance — provider and customer responsibilities
- eduKate: The Gold Standard of Cloud Computing — dependable service boundaries
- eduKate: Data Centre Companies — the physical infrastructure layer
- eduKate: Cybersecurity Companies — authorised incident investigation
- eduKate: Software Companies — application and release control
This is an educational analysis of company management, not an assessment of a real cloud provider, MTCS certificate, personal-data transfer or SLA entitlement. The provider, outage and metrics are fictional. Actual duties depend on contracts, service scope and current applicable laws.