McCloud and the Dutch record behind a cloud name

Summary

• McCloud's public identity is unusually coherent for a small cloud provider: its website, Dutch registration number, Zaandam address, telephone number, RIPE organisation record, AS60358 and visible IPv4 route all point to McCloud.nl B.V. That chain establishes an accountable operator, but it does not validate every performance or security claim on the sales pages.
• The service offer spans online backup, hosted email, a managed workplace, private cloud, file collaboration and online communications. This breadth can reduce coordination work for a smaller customer, while also concentrating identity, storage, support and recovery dependencies in one provider.
• Network records show one widely visible IPv4 /24 originated by AS60358, two observed upstream neighbours and a valid RPKI origin authorisation. Those are useful signs of resource stewardship, not evidence of three-site resilience, workload location, sufficient capacity or application availability.
• A serious purchase should convert the website's promises into dated records: the legal service schedule, named facilities and subprocessors, data-flow map, access model, retention policy, restore results, route and RPKI ownership, support roster, incident clock, migration plan and tested exit procedure.

The name resolves to an accountable Dutch operator

Cloud brands often ask a buyer to begin with a leap of faith. A name appears in a directory, an address block or a sales result, while the legal company, technical operator and support desk remain difficult to join. McCloud is a more encouraging case because several independent identifiers converge. The BTW directory entry supplies the public name and a network-infrastructure frame. The company website presents McCloud.nl as a Dutch provider for small and medium-sized businesses and gives a Zaandam address, telephone number and email address. Its contact page adds Chamber of Commerce number 54366062 and a Dutch VAT number.

The number-resource record matches rather than merely resembling that identity. The RIPE organisation entity names McCloud.nl B.V., gives the country as the Netherlands, repeats registration number 54366062, lists Zuiddijk 255 A in Zaandam and carries the same telephone number. It classifies the organisation as a local Internet registry. That match across a commercial site and the regional Internet registry is much stronger than matching a brand name alone. It ties a legal-style identifier, location and published contact points to a party responsible for Internet number resources.

This does not turn RIPE into a substitute company register. RIPE's concern is administration of addresses and autonomous-system numbers, not corporate ownership, solvency, director authority or the enforceability of a customer agreement. The public website is controlled by the seller, and its registration number is not an official extract. A buyer should still obtain a current Dutch registry extract, verify who can bind the company and make sure the name on the order form, data-processing agreement, invoices and bank details is the same one.

The point is narrower: the public trail contains enough matching attributes to move McCloud from an ambiguous label to an attributable Dutch operator.

The identity also has a human layer. McCloud's about page names two directors, Ron Kooi and Jeroen Wijker, plus staff in software development, systems administration, IT support and administration. A named team is useful because managed infrastructure depends on people who can interpret a failure, approve an emergency change and communicate with a customer. Yet a team page is not a staffing schedule. It does not show whether every listed person remains in role, who carries an overnight pager, which skills are duplicated, or how an incident is handled when a key individual is unavailable.

That distinction sets the method for assessing the rest of the business. Public evidence should be used to identify responsible surfaces, then converted into questions and contractual records. The company number identifies a counterparty. The office address identifies a contact location. The named staff make local expertise plausible. The network records identify resource administration. None of them, separately or together, proves that a restore will complete inside a promised time or that a privileged account cannot bypass a control. Identity is the first layer of assurance, not the last.

A broad service surface for smaller businesses

McCloud's service catalogue groups its offer into four lines: online backup, cloud computing, Drive and online communication. The cloud branch then divides into hosted email, a managed workplace and private cloud. This is not the profile of a hyperscale infrastructure platform selling raw compute primitives by the minute. It is closer to an outsourced IT operating model for Dutch small and medium-sized organisations that want a familiar workplace, protected files and direct assistance without running every server and application themselves.

That positioning explains the repeated emphasis on simplicity. The seller says customers can avoid tapes, local server rooms, mail-server administration and complex routines. Updates, spam filtering, antivirus, backup and elements of migration move to McCloud. Files become accessible across devices. Capacity can expand without a new hardware purchase. A customer that lacks a large internal IT team may value the bundle precisely because one provider accepts several responsibilities that would otherwise be divided among a cloud platform, backup vendor, mail specialist, managed-service provider and local consultant.

Bundling can create real operating leverage. One support desk may be able to see the relationship between a mailbox problem, a workplace login and a storage quota. A provider that designed the customer's environment may restore it more coherently than a backup vendor that sees only blocks. A local team can translate an owner-manager's business priority into a technical sequence without requiring the customer to coordinate several contracts. McCloud's customer-reference page presents this benefit through selected statements from construction, technical, educational and creative organisations, including praise for reduced backup work and greater mobility.

The same breadth creates concentration risk. If the same identity system unlocks hosted mail, desktops and files, an access failure can affect all three. If backup copies and production workloads depend on the same administration team, network or storage control plane, a single mistake can cross a boundary that looked separate on a product list. If the provider manages migration and holds the only practical knowledge of a customer's configuration, switching becomes harder. A support relationship that feels personal during ordinary work can become a bottleneck if several customers need recovery after a common event.

The references deserve proportionate weight. They show the kinds of customer and benefit McCloud wants to represent, but they are selected and hosted by McCloud. They contain no dates, sample method, project scope or measured baseline. They cannot answer how many migrations succeeded, how many restores missed their objective, how long a typical support ticket waited or how often a customer left. The right use of a reference is to generate a specific peer conversation. A prospective backup customer can ask to speak with an organisation of similar data volume and recovery needs.

A workplace buyer can ask about application compatibility, onboarding and the first serious incident.

The commercial comparison should therefore be made at the operating-model level. McCloud is not only selling storage or a virtual machine. It is offering to replace pieces of local administration with a recurring service relationship. The buyer must calculate the internal hours and capital avoided, then add subscription charges, migration work, connectivity, licensing, security review, exception handling, restore exercises and exit preparation. A lower visible infrastructure bill can be misleading if the customer must keep substantial internal expertise to verify the service.

Equally, a higher managed price can be economical if it removes fragmented systems and shortens real recovery work. The public pages do not publish enough pricing or scope to decide; the proposal and service schedule must do that work.

The network footprint is real, narrow and useful

McCloud has a direct public routing identity. The RIPE autonomous-system entity for AS60358 gives the network the name McCloud, links it to McCloud.nl B.V.'s organisation record and shows assigned status. Its registered routing policy names AS174 and AS51088. A RIPE Database search around 5.44.79.0/24 places that route inside an allocation held by McCloud.nl B.V. and includes a route object describing the /24 as McCloud.nl with AS60358 as origin.

Observed routing is consistent with the registration. The RIPEstat overview reported AS60358 as announced on July 14, 2026. Its announced-prefix view showed 5.44.79.0/24 throughout the selected two-week interval. The routing-status response counted one IPv4 prefix, representing 256 addresses, and no qualifying IPv6 announcement at the observation time. It also reported that every listed IPv4 RIS peer saw the origin, while the neighbour view identified AS174 and AS51088 as the two observed neighbours.

This is a modest footprint, but modest is not synonymous with weak. A focused provider may need only a small public address range. Full visibility in the reported collectors suggests that the /24 was not an obscure or barely propagated route at that moment. Two upstream relationships can provide more options than one. The first-seen field, March 2014 for the visible origin relationship, indicates continuity of an observable network edge over a long interval.

Most importantly, the website itself resolved to an address inside that /24 during the research observation, joining the sales domain to the operator's registered route rather than to an unrelated mass-hosting network.

The route also had a sound authorisation signal. RIPEstat's RPKI validation response reported the AS60358 origin for 5.44.79.0/24 as valid, backed by a route-origin authorisation with a maximum length of /24. That record helps networks reject an unauthorised origin for the prefix when they perform route-origin validation. For a small provider, maintaining a correct authorisation is concrete evidence that someone is attending to a basic part of route governance.

But the limits are as important as the signals. One /24 does not reveal the number of customers, servers, storage nodes, sites or private networks. Two observed neighbours do not prove physically diverse fibre paths, separate building entrances or independent failure domains. The registered policy was last modified years before the observation and may not describe every current arrangement. Collector visibility does not measure customer latency, packet loss, congestion or application health. A valid RPKI origin cannot stop compromised credentials, a mistaken firewall rule, a route leak along an authorised path or an outage inside the service.

There was no public AS60358 entry returned by the PeeringDB API during the observation. That absence should not be converted into a claim that McCloud lacks interconnection or facility presence. PeeringDB participation is voluntary, and private transit relationships need not appear there. It does mean a buyer cannot use that directory to cross-check declared facilities, exchanges, traffic policy or network contacts. The provider should be ready to supply the relevant topology under appropriate confidentiality, including carriers, hand-off sites, route monitoring, mitigation arrangements, IPv6 plans and the customer-notification procedure for network changes.

Dutch locality has to be mapped, not assumed

McCloud repeatedly presents locality as part of its offer. The cloud-computing page says customer data is held in three geographically distributed Dutch data centres. The about page describes Dutch sites working as one storage platform, with files divided into blocks and distributed so that a subset can reconstruct the whole. The backup and Drive pages likewise say data is stored in Dutch infrastructure. For a Dutch business concerned about jurisdiction, latency or access to local support, that is a meaningful proposition.

Yet "in the Netherlands" is only the first coordinate in a data-location map. A production file can remain in a Dutch facility while its account metadata, monitoring events, support attachments or email telemetry are processed elsewhere. A backup can be stored locally while encryption keys are administered through another country. A local private cloud can depend on a remote software repository or vendor support channel. A Dutch engineer can access a system through an identity provider whose logs and recovery controls sit outside the country.

None of these arrangements is automatically unacceptable, but each has different legal and operational consequences.

The buyer should ask for a service-specific data-flow schedule. It should identify where primary content, replicas, backups, logs, account records, billing records and support evidence are stored and processed. It should name each data-centre operator and subprocessor, rather than using the provider's brand as a location. It should show where keys are generated, held, backed up and recovered. It should identify normal and emergency administrator locations, remote-support paths and any vendor that can receive diagnostic data.

Retention and deletion should be stated for every major class, including the time required to remove expired replicas and backups.

Three data centres also do not automatically create three independent failure domains. They may share a carrier, power supplier, identity service, storage-control plane, monitoring platform or administrator group. Geographic separation can protect against a building event while doing little against a faulty software update applied everywhere. A block-distribution design can tolerate some storage-node loss while remaining vulnerable to corruption, stolen credentials or an error in the metadata needed to reconstruct files.

A buyer needs both physical and logical dependency maps, followed by tests that remove a component and record what actually happened.

The public website does not name the three facilities or publish certifications. Its about page says the data centres work to strict international requirements for security and continuity, but supplies no standard names, certificate numbers, scopes, issuers or expiry dates. That is a claim to verify, not a reason to presume non-compliance. The provider may have assurance documents that it does not publish.

In due diligence, the customer should obtain current certificates and reports, check that the legal entity and selected facilities fall within scope, review exceptions, and confirm whether the controls cover McCloud's management processes as well as the building operator.

Locality should finally be tested during failure and exit. Where does service run when a primary site is unavailable? Does a disaster-recovery copy stay in the Netherlands? Can support personnel export a database to diagnose an incident? When a contract ends, what format does the customer receive, through which route, and how are remaining copies erased? A locality promise is strongest when it survives migration, emergency operation and deletion, not merely when a sales diagram shows three Dutch points.

Backup claims become valuable only after a restore

The online-backup page contains some of McCloud's most concrete technical claims. It says data travels over a secured connection to Dutch data centres, is encrypted with a customer's own key, begins with a full copy and then sends changes. It names IASO software and Amplidata BitSpread as components. It presents automation as the main labour saving: configure a schedule once, then let the service run without tapes or external drives.

That model addresses a common weakness in smaller organisations. Manual backups compete with daily work and are easy to postpone. Removable media can remain attached, be lost or fail silently. An incremental online process can shorten routine transfer time and create an off-site copy without requiring a staff member to carry media. Central monitoring can reveal missed backup runs across several machines. Recurring pricing turns a capital purchase into a service expense and can make growth easier to budget.

Automation also changes the work rather than removing it. Someone must decide which systems and data are protected, how frequently they are copied and how long versions are retained. New servers, software-as-a-service data and employee devices must be added. Failed backup runs need triage. Encryption keys must be stored in a way that protects them from attackers without making recovery impossible when the original administrator is absent. Restore tests have to prove that files are usable and that application dependencies, permissions and databases return in a coherent order.

McCloud advertises a disaster-recovery option that reserves extra infrastructure, creates a plan with the customer and says the IT environment can be running within 12 hours after a calamity. Twelve hours sounds specific, but the page does not define the starting event, covered systems, priority order, recovery point, required customer decisions or remedy if the interval is missed. "Up and running" could mean core servers have booted, or it could mean every user and external integration is productive. A contract should define the clock, workload, data state, test conditions, exclusions and acceptance evidence.

The storage reliability language needs similar care. The about and backup pages describe data blocks spread across sites and claim up to 15 nines of availability or reliability. Such a number cannot be evaluated without knowing whether it refers to entity durability, read availability, a component design target or a measured end-to-end service. It says nothing by itself about account compromise, malicious deletion, ransomware synchronisation, software defects or the ability to restore an application.

The customer should ask for the calculation, measured interval, included failure modes, current architecture and contractual commitment, then compare those with actual restore results.

A useful backup acceptance pack is operational. It lists every protected workload and owner. It records the intended recovery point and recovery time. It shows backup-run success and failure over a representative period. It documents retention, immutability or separation from production credentials, key custody and alert escalation. Most importantly, it contains dated restore exercises: a single file, a mailbox, a database, an entire server and a multi-system business process. Each exercise records copy date, restored state, elapsed time, data loss, manual steps and unresolved defects.

Customers should also understand deletion and exit. A backup provider can make entry easy while holding data in a format that is slow to export at scale. The proposal should explain bulk recovery speed, media options, network charges, export formats, final-copy handling and deletion confirmation. If recovery depends on proprietary software, the customer needs a plan for licence continuity during an emergency or provider failure. A backup is not truly under control when only the incumbent can interpret it.

The managed workplace moves the control plane

McCloud's Online Workplace offers a familiar Windows-style environment, applications, files and settings across devices, with updates, spam filters and antivirus managed by the provider. Its Hosted Exchange page adds managed email, calendars and contacts, plus migration, backups, encryption and redundant storage. The wider cloud page identifies Exchange 2013, a specific platform reference that a buyer should clarify in a current proposal rather than assuming the public page reflects today's deployed version.

For a smaller business, moving the workplace can standardise machines and reduce dependence on an office server. New users can receive a consistent environment. A damaged laptop need not contain the only working copy of a file. Patching and malware controls can be managed centrally. Hosted mail can remove the need to maintain an Exchange server on premises. These are meaningful advantages when the alternative is a collection of ageing devices and informal administrator habits.

The move also shifts the control plane. The provider may administer user sessions, base images, mail transport, backups, security software and the network edge. A compromised privileged account can therefore reach several customer systems. A mistaken image update can affect many users at once. An identity outage can make healthy applications inaccessible. A software vendor's licensing or support change can become the customer's problem even when McCloud operates the platform. The buyer needs to know exactly which decisions the provider can make, which require approval and which remain the customer's responsibility.

Identity is the central boundary. The public pages do not describe multifactor authentication, federation, conditional access, privileged-access workstations, break-glass accounts or administrator session recording. Those omissions do not prove the controls are absent; they identify the questions that matter. The customer should require separate administrator identities, least privilege, rapid joiner-mover-leaver processing, approval for exceptional access, logs that the customer can obtain, and a tested method to regain control if the normal identity service fails.

Endpoint and application boundaries matter too. "Available on any device" does not state whether data can be downloaded to an unmanaged computer, copied to local storage, printed or placed on a clipboard. A standard image may not support a specialist application, peripheral or latency-sensitive work pattern. Antivirus does not replace application allow-listing, patch governance or phishing-resistant authentication. A pilot should include the hardest real applications and devices, not only office documents, and should test a slow connection, lost endpoint, password reset and emergency support case.

Migration deserves its own record. McCloud says a customer can move all at once or in stages. A staged move can reduce risk, but coexistence creates temporary dependencies: mail routing between systems, duplicate identities, file-version conflicts and support ambiguity. The migration plan should inventory users, mailboxes, applications, permissions, shared drives, archives, devices and integrations. It should define data reconciliation, rollback, user communication and acceptance. Every item that cannot be moved without redesign should be identified before the commercial commitment.

Finally, the exit plan should be agreed while entry is still optional. The customer needs export formats for mail, files, virtual machines, configurations and logs. It needs enough time and access to validate exports before deletion. Domain names, certificates, administrator credentials and any customer-owned licences must have clear owners. The provider should explain how it will cooperate with a successor and how fees are calculated. A managed workplace creates value by absorbing complexity; it should not turn that complexity into captivity.

Private cloud requires a definition of private

The Private Cloud page offers dedicated servers and an environment said to be exclusive to one customer. It positions the service for stricter compliance, audit or security requirements and says McCloud will design capacity, backups and disaster recovery with the buyer. This is a sensible option for an organisation whose applications, licences or risk posture do not fit a shared platform.

"Dedicated" can describe several different boundaries. Compute hosts may be dedicated while storage controllers, network devices, backup platforms and management software remain shared. Physical hardware may be exclusive while administrators use common privileged systems. A network segment may be private while monitoring and logging flow through a multi-tenant service. Encryption keys may be customer-specific while recovery keys remain available to the provider. None of these designs is inherently wrong, but the word private does not choose among them.

The architecture schedule should therefore name the isolation boundary for compute, memory, storage, network, backup, keys, management, monitoring and staff. It should state which components are dedicated, logically separated or shared, and identify the controls around every shared layer. Capacity promises should include usable rather than raw resources, expected contention and the process for expansion. Security responsibilities should show who patches the hypervisor, guest operating systems and applications, and how vulnerability exceptions are approved.

Audit needs records, not only architecture. A regulated customer may need proof of access reviews, changes, backups, vulnerability treatment, incidents and deletion. The provider should say which logs exist, how long they remain available, whether time is synchronised and how the customer can export them. Emergency actions should leave an attributable trail. If McCloud relies on a data-centre operator or technology vendor, the customer needs assurance that supporting evidence can flow through those relationships rather than stopping at a subcontract boundary.

Private cloud can also increase lifecycle risk. Dedicated equipment ages, and a customer's unusual configuration may become harder to patch or replace. Reserved capacity can improve predictability while reducing the provider's ability to shift workloads during a failure. A hardware refresh may require migration even if the application has not changed. The business case should include refresh intervals, spare strategy, support contracts, end-of-life notices, expansion lead times and the treatment of residual hardware value.

A practical proof is a recovery exercise that removes a dedicated component and follows the service through failover. Does the workload restart on equally isolated capacity? Are network rules and keys recreated correctly? Does the backup platform preserve the promised boundary? Who authorises emergency use of shared infrastructure, and is the customer informed before or after? The answers determine whether private describes a resilient operating model or only the normal-state hardware allocation.

Drive places permissions at the centre of collaboration

The McCloud Drive page describes a Dutch alternative to broad consumer file-sharing services. It offers synchronisation across devices, offline work, internal and external collaboration, central storage and rights at project or file level. It says content is encrypted and redundantly stored in Dutch cloud infrastructure. For teams that exchange documents by email or maintain several conflicting shared-drive copies, the working appeal is clear.

The automation benefit is version and access coordination. A shared service can give collaborators the latest file, propagate changes when a device reconnects and remove the need to attach large documents repeatedly. Project-level membership can be easier to administer than a collection of local folders. External users can enter a defined workspace rather than receiving a permanent copy by email. Central storage can also make backup, retention and departure handling more consistent.

Permissions become the main risk. A wrong group membership, reusable public link or inherited folder right can expose more than a user intended. Offline synchronisation creates local copies beyond the central platform. A departed contractor may retain a synchronised folder or active token. Ransomware can encrypt files and allow a legitimate synchronisation client to distribute the damage. Encryption and redundancy help with some threats, but neither tells the customer who can decrypt, how versions are recovered or how anomalous sharing is detected.

The buyer should test the complete permission lifecycle. Create internal and external users, restrict them to one project, attempt access to a neighbouring folder, change roles, revoke access and inspect what remains on an offline device. Review whether links expire, can require authentication and can be limited to named recipients. Determine whether administrators can see effective permissions and export an access report. Ask how long deleted and prior versions remain available, how mass changes are detected and what a large ransomware restore would take.

Governance requirements vary by document. Ordinary working files may need flexible sharing, while personnel, legal or customer records may require tighter retention and access. The public page does not mention classification, legal hold, data-loss prevention or records-management functions. A customer should not infer them from a general security claim. Instead, it should map data classes to allowed Drive use, configure controls where available and keep unsuitable records in a system built for their obligations.

Portability is again important. Synchronised files may be easy to retrieve one by one while a large repository with versions, metadata, project structure and permissions is difficult to move. The customer should ask what an export preserves and how long it takes at realistic scale. It should also determine whether audit history can be retained after departure. Collaboration creates value from relationships around files, not only the file bytes, so an exit that loses those relationships may be costly even if every document is returned.

Security statements need service-specific evidence

McCloud's privacy statement says the company uses TLS, DKIM, SPF, DMARC, virus scanners and firewalls, enters processing agreements with service providers, retains personal data no longer than needed and recognises rights of access, correction and deletion. These are sensible baseline signals. The policy also provides a direct route for reporting a suspected security problem. It helps identify how the public website and commercial relationship handle contact data.

The statement is not a full security annex for hosted workloads. Email-authentication controls protect particular message flows; they do not define workplace access or backup isolation. TLS protects data in transit under stated conditions; it does not settle key custody, endpoint security or administrator access. Firewalls and virus scanners are categories, not configurations or measured outcomes. Purpose-based retention is a principle, not a schedule that tells a customer when a backup, log or support attachment disappears.

Each service needs its own control description. Backup requires source authentication, encryption, retention, immutability, restore access and separation from production credentials. Hosted email requires modern authentication, anti-phishing controls, mail-flow protection, archive and recovery rules. A workplace requires endpoint policy, privileged access, session controls, patching and logs. Drive requires sharing governance, version recovery and external-user lifecycle. Private cloud requires isolation, vulnerability management, network controls and evidence export.

A generic list cannot show whether the control reaches the service where it matters.

The buyer should request current assurance materials and evaluate their scope. A penetration test of the public website says little about a backup client. A data-centre certificate may not cover McCloud's administrator practices. A vendor certificate may apply to software while excluding the customer's configuration. Findings and exceptions matter as much as a logo. The review should ask when testing occurred, what was included, who performed it, which issues remain and how remediation was verified.

Incident handling should be made concrete before an incident. The contract needs severity definitions, notification clocks, escalation contacts, evidence-preservation duties and a method for sharing updates when normal systems are unavailable. It should state who leads when the event crosses McCloud, a facility operator, a software vendor and the customer. The customer should know whether it can obtain relevant logs and a final report. A tabletop exercise can reveal gaps in contact authority and decision timing at far lower cost than a live compromise.

The provider's public record does not reveal a material breach history, independent incident statistics or response-time distribution in the fixed evidence. That absence should not be portrayed as proof of a perfect record or as a hidden problem. Small private providers often publish less operational data than large platforms. The proper conclusion is uncertainty, followed by proportionate diligence: request evidence, speak to comparable customers, test high-impact controls and allocate responsibility in writing.

Local support is a production dependency

McCloud makes personal service part of its differentiation. Its website emphasises direct advice, quick help and a team in Zaandam. The staff page names people in direction, software development, systems administration, IT support and administration. The contact page provides a Dutch telephone number and visit address. For a customer that has struggled with anonymous global help desks, access to people who know the environment can be a significant benefit.

Locality can shorten the social path to a decision. A technician familiar with the customer's application may recognise that a mailbox symptom comes from an identity change. A director in the same organisation may be reachable when a recovery needs commercial authority. Shared language and working hours can improve migration and training. Site visits may be practical. These advantages are difficult to capture in a generic cloud-price comparison, yet they often determine how quickly a small business returns to work.

Personal support can also create key-person risk. A six-name public team cannot by itself demonstrate continuous coverage across systems administration, networking, security, storage, mail and application support. The pages do not publish help-desk hours, after-hours arrangements, severity response targets, ticket volumes or escalation depth. A customer should ask who answers outside normal hours, which cases trigger an on-call engineer, whether directors are part of escalation, and how knowledge is transferred when the usual technician is absent.

Support quality should be measured at the case level. Useful records include time to acknowledge, time to qualified ownership, time to workaround, time to restore, number of hand-offs, reopen rate and customer waiting time. Severity must reflect business impact rather than the technical size of the fault. A single locked administrator account can be critical even if every server is healthy. The provider and customer should agree who can declare severity, who can authorise disruptive recovery and how disagreements are escalated.

The support boundary must be equally clear. In a managed workplace, does McCloud troubleshoot a customer's line-of-business application or only the hosted operating environment? In Drive, does it recover an accidentally changed folder permission? For backup, who verifies application consistency? For private cloud, who patches guest systems? Ambiguous ownership creates the longest delays because each party waits for the other to act. A responsibility matrix should name the operator, approver, consultant and informed party for routine and emergency tasks.

Labour cost belongs in the commercial assessment. A service may automate backups and updates while creating review work for access requests, exceptions, restore testing and supplier oversight. The customer still needs someone who understands business priorities and can challenge a technical answer. McCloud still needs enough staff to monitor, document and recover the platform. The goal is not to eliminate human work, but to move it toward the decisions where judgement matters and make every hand-off visible.

Extraordinary claims should become ordinary records

McCloud's about and backup pages use unusually strong reliability language. They attribute a claimed maximum of 15 nines to the BitSpread storage technology, describe distributed reconstruction across Dutch data centres, and state an energy intensity of 3 watts per terabyte with green electricity. The backup page calls the storage technology award-winning and presents its reliability as beyond traditional backup. These statements create a clear burden of explanation because the public pages do not supply the measurement scope or current supporting documents.

A buyer need not dismiss a striking claim merely because it appears in marketing. Erasure coding and distributed storage can materially improve durability and efficiency. The right response is to ask what the number means. Is it a theoretical probability of entity loss, an availability target for reads, a component specification or a measured service result? Over what period and entity population? Which failures are included? Does the calculation assume independent sites, and are those assumptions demonstrated? Does it cover metadata, keys, account access and recovery software as well as data blocks?

Technology names also require lifecycle verification. The pages name Amplidata, BitSpread, IASO and Exchange 2013. A product reference can accurately describe the origin of a design while no longer identifying the current version, owner or support arrangement. The proposal should list deployed products and versions, support status, patch ownership, replacement plans and migration consequences. The customer should know whether a vendor can still provide fixes and whether McCloud has the source, expertise or alternative needed if a dependency ends.

Sustainability claims deserve the same treatment. Three watts per terabyte could refer to a storage component, a selected operating point or a broader platform boundary. Green electricity can mean several procurement arrangements. A useful environmental record identifies the measurement boundary, period, energy source, facility overhead, utilisation and treatment of certificates. It should distinguish a design advantage from an audited service footprint. Without that context, the figures may still signal an engineering priority, but they cannot support a precise purchasing comparison.

The most persuasive reliability evidence is routine and dated. Capacity and error trends show whether the system is operating within design assumptions. Incident histories reveal how failures propagate. Restore exercises show whether protected data returns. Facility and carrier tests show whether redundancy works under interruption. Change records show whether upgrades are controlled. A provider that can produce these records turns architecture language into trust without needing the buyer to accept a superlative.

A buyer's evidence schedule

McCloud's public record is strong enough to justify a detailed conversation. It is not strong enough to skip one. The first document should identify McCloud.nl B.V. as the counterparty, repeat registration number 54366062 and name the authorised signer. It should list every affiliate, facility operator, software provider and other subprocessor that can affect the selected service. Brand names on product pages should be translated into accountable legal parties.

The second document should map the service. For networked workloads, it should show the customer edge, AS60358, address ownership, upstream relationships, mitigation arrangements and monitoring. For data, it should locate content, replicas, backups, logs, metadata and keys. For administration, it should identify identity systems, privileged roles, normal work locations and emergency paths. For support, it should give hours, severity rules, escalation contacts and decision authority. Each map needs an owner and review date.

The third should define measurable outcomes. Availability must name the service boundary and exclusions. Backup must have recovery-point and recovery-time objectives. Support must have acknowledgement and restoration clocks. Security must define notification, evidence and remediation duties. Locality must apply to named data classes and failure modes. Credits can create discipline, but the more important remedy is a tested process that restores the customer's operation.

The fourth should contain test evidence. A buyer should observe at least one restore, one identity recovery, one network or access failover and one export before moving critical work. The tests should use realistic data volumes and application dependencies. Failures should remain in the record until corrected and repeated. After onboarding, a calendar should repeat tests and review routes, RPKI, permissions, staff access, certificates, capacity and subprocessors.

The fifth should make exit executable. It should list export formats, bandwidth and media options, lead times, assistance rates, licence dependencies, domain and certificate ownership, data-deletion timing and evidence of completion. The customer should maintain its own current inventory and essential credentials. A small rehearsal can prove that files, mail, virtual machines, configurations and logs are portable before urgency removes negotiating power.

Commercial evaluation then becomes more honest. The subscription price sits beside migration, licences, connectivity, retained customer staff, assurance reviews, restore exercises and exit. Benefits include avoided hardware, reduced routine administration, faster local support and the value of a coherent recovery process. Risks include concentrated dependencies, uncertain service claims and the cost of switching. The decision should be based on the full operating boundary, not a cloud label or one routing metric.

McCloud's name is backed by more than branding. The identity chain is coherent, the network route is visible, the origin is authorised and the service pages describe a plausible Dutch managed-cloud business. The remaining gap is between plausible and proven. McCloud can close it by showing how its records stay current, how its people act under pressure and how customers recover and leave. A buyer can close its side by asking for those records before the service becomes indispensable.