Cloud Temple's qualified services still need product-by-product

Summary

ANSSI's decision identifies IAAS - SECURE TEMPLE as a qualified IaaS service supplied by CLOUD TEMPLE, while Cloud Temple's compliance page describes additional scopes and attestations. Those records are meaningful evidence for named services, not proof that every product, zone, supplier, customer configuration or workload receives the same controls.
Cloud Temple's product pages describe materially different responsibility boundaries. VMware IaaS, OpenSource IaaS, Object Storage, Private Backbone and Housing each expose different assumptions about replication, backup, networking, customer control, physical space and portability. The Housing page is especially clear that its dedicated-space offer is in a non-SecNumCloud zone.
AS33930, RIPEstat and PeeringDB make part of the network surface inspectable. They connect CLOUD TEMPLE to public number resources, observed announcements, exchange capacity and facility listings, but do not establish traffic volume, spare capacity, route diversity, customer path selection, supplier roles or ownership of any listed facility.
The practical diligence task is to join four things for each purchased design: the exact qualified or attested service, the deployed architecture, the division of operating duties, and the contract evidence for suppliers, incidents, recovery and exit. A portfolio-level badge cannot perform that join on the customer's behalf.

The most useful disclosure is the exception

A small sentence on Cloud Temple's Housing page does more analytical work than a page full of general assurances. The company describes shared or dedicated racks, dual electrical chains, meet-me-room connectivity and on-site support, but it also says that the dedicated-space product is hosted in a non-SecNumCloud zone. That is not a weakness in the disclosure. It is the clearest available guide to how the portfolio should be read.

The distinction matters because buyers often encounter a cloud provider first through its strongest assurance. In this case, the public record includes an ANSSI qualification decision, a compliance page discussing SecNumCloud 3.2, and product material that uses the language of qualified services. It would be easy to let that evidence colour every adjacent offer. The Housing page prevents that shortcut. A customer may buy from the same provider, deal with the same commercial counterparty and still cross into a different control environment when the selected service changes.

That boundary is operational, not semantic. Housing gives a customer physical space and related site services. IaaS supplies an abstracted computing platform. Object storage has its own replication, interface and retention behaviour. A private backbone introduces circuits, addresses, VLANs, security controls and choices about topology. Those products can be combined, but combination does not erase their separate scopes. It creates handoffs between them.

The right question, then, is not whether Cloud Temple is "a SecNumCloud provider" in the broadest conversational sense. It is whether the exact service, zone, option and supporting component in a proposed architecture fall within the evidence being relied upon. The Housing disclosure makes the answer visibly capable of changing from one line item to the next. Any serious assessment should preserve that product-level resolution all the way from procurement through operations and exit.

Qualification attaches to a named service

The strongest independent evidence in the public record is specific. ANSSI's public decision names IAAS - SECURE TEMPLE, describes it as IaaS supplied by CLOUD TEMPLE and makes the qualification conditional on continuing compliance during a defined validity period. The name is important. So is the conditionality. A qualification decision is not an abstract endorsement of every activity undertaken by the supplier; it identifies a service and a bounded assurance state.

Cloud Temple's compliance material broadens the public picture without making it universal. It presents SecNumCloud 3.2 scopes for IaaS Secure Temple and PaaS OpenShift, and it discusses HDS, ISO 27001, C5 and other assurance material. These labels are useful starting points, but they are not interchangeable. Each has its own subject, scope, period and evidentiary purpose. Even when several appear on one compliance page, they should not be compressed into a single claim that everything sold by Cloud Temple is covered in the same way.

For a buyer, the exact naming needs to survive into the contract and design record. IAAS - SECURE TEMPLE in an ANSSI decision, Secure Temple in commercial discussion, a particular IaaS configuration on an order form and the resources actually deployed must refer to the same intended service boundary. If a project also uses OpenShift, object storage, a private backbone, housing or an external circuit, each addition needs its own answer. Is it included in the relevant scope, merely adjacent to it, or outside it?

The time dimension matters as well. The decision described in the public material has a defined validity period and depends on continued compliance. That supports a disciplined evidence calendar: record which decision or certificate was relied upon, when it applied, what exact service it named and what happens if the status or scope changes. It does not justify predicting future qualification, nor does it prove that a customer's configuration remained compliant simply because the provider-level decision remained current.

Legal identity is clearer than the directory label

The French public enterprise-search API identifies CLOUD TEMPLE as an active legal unit with SIREN 825400336, created on 17 January 2017 and classified under data processing, hosting and related activities. It places the headquarters at 1-7 Le Belvedere, 1 Cours Valmy, Puteaux. Cloud Temple's website terms identify the publisher as a French single-shareholder simplified joint-stock company at the same address. Together, those records provide a stable counterparty anchor for the services and public network identity discussed here.

This is also where naming discipline matters. The BTW directory uses TEMPLE Cloud Temple SAS as its existing entity label, which is why that string appears in the Overview. Public evidence supports CLOUD TEMPLE as the legal and reader-facing identity. It does not establish TEMPLE Cloud Temple SAS as the official current legal name, and this article does not treat it as one.

Counterparty identity is necessary but not sufficient for service responsibility. A matching legal name, registration number and address tell a buyer which organization publishes the terms and appears in the qualification decision. They do not show which third party runs a particular facility, supplies a circuit, provides a component or carries traffic. Nor do they answer whether a given obligation sits with Cloud Temple, the customer or another supplier. Those answers belong in service schedules, architecture records and supporting assurance evidence, joined back to the identified legal counterparty.

A portfolio needs a responsibility map

Cloud Temple's public catalogue is best understood as a set of control surfaces rather than as a single stack. At one end, a qualified IaaS service can place extensive platform duties with the provider. At another, housing leaves the customer's own equipment and many operating choices inside a physical service that explicitly sits outside the SecNumCloud zone. Between those ends are products that mix provider-operated infrastructure with customer-selected topology, retention or workload configuration.

There are at least four layers to map. The first is the service itself: what exact product and option was ordered? The second is deployment: which zones, hosts, storage classes, backup settings, addresses and circuits were actually selected? The third is operation: who monitors, patches, configures, tests, approves change and responds when a component fails? The fourth is evidence: which qualification, certificate, report, supplier document or contractual schedule supports each control claim?

These layers cannot be collapsed into a logo or a product-family name. A qualified service may still require the customer to configure networks and access correctly. A replicated storage product may still require retention choices and tested extraction procedures. A multi-zone option may exist without being selected. A stated recovery target may be conditional on the purchased design and on actions by both parties. A facility listing may identify a place without saying what equipment or service is there.

The responsibility map should therefore be specific enough to reveal gaps. If an application depends on IaaS, object storage and a private circuit, the record should show three product boundaries and the handoffs among them. If housing is added for an appliance or legacy system, its non-SecNumCloud status should remain visible rather than being absorbed into a general statement about the surrounding platform. The value of Cloud Temple's disclosure is that it gives buyers the raw distinctions needed to build that map. The remaining work is to bind them to the purchased architecture.

VMware IaaS publishes targets, not outcomes

The VMware IaaS page describes a comparatively rich service design. Cloud Temple says it provides dedicated compute, network, storage and backup infrastructure, offers multi-zone deployment, and uses asynchronous storage replication. It states a 15-minute recovery point objective, a recovery time objective below four hours and 99.99% availability. These are provider-published specifications. They make the intended service measurable, but they are not observations of how a particular customer environment performed.

That distinction is essential for resilience analysis. A stated recovery point objective describes a target for tolerated data loss under the relevant conditions. It does not prove that every workload was in scope, that replication was healthy at the moment of failure, or that application-consistent recovery was achieved. A recovery time objective describes a target for restoration, not evidence that dependencies, credentials, network rules and application teams completed an actual recovery inside that window.

Availability language likewise requires the contractual definition, exclusions, measurement point and remedy before it can be applied to a customer outcome.

The word "dedicated" also needs service-level interpretation. The page ties it to compute, network, storage and backup infrastructure, which is a substantive description. A buyer still needs to know which elements are dedicated in the ordered design, where shared management or facility dependencies remain, and how the boundary is evidenced. Multi-zone capability needs the same treatment: which zones are selected, which components span them, and which dependencies could still be common?

None of those questions contradicts the product page. They are how its claims become operationally useful. The page supplies design features and numerical targets that can be placed into a test plan and contract matrix. Independent proof would come from the purchased architecture, monitoring records, exercise results and applicable service terms. Without that join, the published figures should be attributed to Cloud Temple and kept separate from claims about actual SLA performance or recovery success.

OpenSource IaaS draws a different boundary

Cloud Temple's OpenSource IaaS page describes Xen virtualisation, high availability from two hosts, live migration, entity-storage backup and automatic backup distribution across three availability zones. The vocabulary overlaps with the VMware offer, but the control pattern is not identical. Different virtualisation, host and backup descriptions mean that assurance cannot simply be copied from one IaaS product to another.

High availability from two hosts is a platform design statement. Its customer significance depends on workload placement, host independence, shared storage or network dependencies, and the failure modes the mechanism is intended to handle. Live migration can support maintenance and workload movement, but it is not by itself a disaster-recovery result. Backups placed in object storage and distributed across three availability zones add another resilience layer, yet the existence and distribution of backup copies do not prove that a usable restore has occurred.

The operating handoff also differs by layer. Cloud Temple can provide host-level mechanisms, migration capability and backup distribution while the customer remains responsible for guest configuration, application consistency, credentials, retention choices or restore acceptance, depending on the contract. The public page does not establish the exact allocation for every customer. It does show why that allocation needs to be written down for this product rather than inferred from the VMware description or from a portfolio-level compliance claim.

A useful assessment would connect each published mechanism to a failure scenario. Two-host availability addresses some host events. Live migration addresses some planned or emerging conditions. Distributed backups address preservation of copies. None necessarily resolves an application defect, compromised credentials, deletion protected by the wrong retention policy or a dependency outside the platform. The point is not to diminish the architecture. It is to identify what each control is designed to do, who must activate or verify it, and what evidence would demonstrate that the customer's implementation can use it.

Object Storage makes portability tangible and conditional

The Object Storage page is unusually relevant to both resilience and exit. Cloud Temple markets the service as SecNumCloud-qualified, S3-compatible, replicated across three availability zones and free of egress charges. It also notes constraints associated with Object Lock. Those statements expose a useful combination: assurance and portability features on one side, retention behaviour that can restrict change on the other.

S3 compatibility can reduce application friction because a familiar interface may support common tools and workflows. Compatibility, however, is not a guarantee that every API behaviour, policy model, metadata field, lifecycle rule or operational tool will transfer unchanged. A real exit plan needs an inventory of what the application uses, not just the protocol label. It also needs a destination, credentials, transfer method, integrity checks and enough time to move the data.

The absence of egress charges, as presented by the provider, removes one potential price component. It does not establish that exit is free. Engineering labour, destination charges, temporary duplicate storage, circuit capacity, request costs, validation and application change can still shape the economics. Nor does it prove that a transfer will complete by a desired date. Throughput and timing depend on a deployed situation that the public page does not document.

Object Lock makes the responsibility boundary sharper. Retention that prevents alteration or deletion can be valuable, but the same constraint can affect migration and closure. A buyer should know who chooses the mode and period, how legal or policy obligations are represented, what can be copied while locked, and when deletion becomes possible. The public material supports the existence of constraints, not a universal exit outcome.

The strongest interpretation is therefore conditional: Cloud Temple publishes features that can support portable and resilient storage, while the customer's configuration and tested extraction process determine whether those features produce the required result.

Private Backbone leaves topology choices with the customer

The Private Backbone page describes regional VPLS networks, public IPv4 and IPv6 allocation, anti-DDoS functions, VLAN controls and external or dedicated circuits at 1 or 10 Gbps. It also says customers can retain manual control of topology and security equipment. That last point is not a footnote. It places a consequential part of the operating model on the customer side of the service boundary.

A provider-run backbone can supply transport, addressing and protective functions without determining the final application path. VLAN design, route choice, security-device policy and the connection between cloud zones, housing space and external locations may reflect customer decisions. Manual control offers flexibility, but it also means that the provider's platform controls cannot be assumed to prevent every customer-created single point of failure or policy mistake.

The advertised circuit rates are product options, not evidence of purchased capacity or observed headroom. A 10 Gbps option does not prove that a customer has ordered it, that the end-to-end path runs at that rate, or that sufficient spare capacity exists during an incident. Likewise, public IPv4 and IPv6 availability says nothing by itself about address assignment for a specific service. Anti-DDoS language identifies a control category, but an assessment still needs activation conditions, protected traffic, handoff points and customer duties.

This mixed-control model is where architecture evidence becomes more valuable than general provider evidence. A diagram should identify which segments Cloud Temple operates, which devices or policies the customer controls, and where third-party circuits enter. Change and incident procedures should say who can modify each layer and how the parties coordinate. The public page supports the existence of a configurable network service. It does not reveal any customer's topology, path selection or security posture, and those private details should not be inferred from the product catalogue.

AS33930 anchors identity, not performance

Public network records give Cloud Temple a checkable infrastructure identity. RIPE RDAP identifies AS33930 under CLOUD-TEMPLE. At the time of the public check, RIPEstat observed eight announced IPv4 and IPv6 prefixes. These records help distinguish an operating network from a cloud brand that leaves no public number-resource trace.

The evidence remains narrow. RDAP is an administrative registration system, so it supports attribution of the autonomous system resource; it does not describe the full service running behind it. RIPEstat observations show that prefixes were visible in routing data at a particular check. They do not measure traffic, usable customer capacity, application reachability or contractual service. A prefix can be announced without proving how customer workloads use it, while private services may matter without appearing as a distinct public announcement.

An autonomous system number is especially tempting to turn into an architecture diagram. Researchers may assume it identifies every upstream, all routes and the complete redundancy design. That record does not support those conclusions. AS33930 establishes a public routing identity. It does not prove route diversity, spare links, geographic independence, failover behaviour or the path taken by any customer packet.

For diligence, the ASN is best used as a reconciliation key. It can be compared with PeeringDB entries, observed prefixes and the network identifiers written into a customer's design. Differences can produce questions: which addresses belong to the purchased service, which paths are private, and which party announces a prefix? The answers must come from current technical and contractual evidence. The public registry gives the inquiry a stable starting point, not a performance verdict.

PeeringDB adds disclosed places, not owned facilities

PeeringDB adds a different type of visibility. Its Cloud Temple entry lists 30 IPv4 and 10 IPv6 prefixes, an open peering policy, two reported 10G exchange presences in Paris, and facilities including DATA4, Digital Realty, Equinix and Telehouse. This is useful disclosure about where the network says it can interconnect and the scale of resources reported to the directory.

The figures do not conflict with RIPEstat's observation of eight announced IPv4 and IPv6 prefixes because they describe different things. PeeringDB's prefix limits or counts are directory fields; RIPEstat reports what its system observed announced at a check. Neither should be silently substituted for the other. More importantly, neither is a traffic measurement. The records do not show load, peak utilisation, customer distribution or spare capacity.

Facility names require equal care. A PeeringDB listing can place a network at a site for interconnection purposes. It does not prove that Cloud Temple owns the building, controls the entire facility, occupies a particular amount of space or deploys the same product at every listed location. DATA4, Digital Realty, Equinix and Telehouse should therefore be understood as named facilities or facility operators in a public network directory, not as assets attributed to Cloud Temple.

The two reported 10G exchange presences in Paris make the public interconnection surface more concrete, but they still do not prove diverse routes or resilient customer delivery. Two reported presences can share dependencies that are invisible in the listing, and customer traffic may follow arrangements not captured there. Open peering describes a stated policy, not a promise that every request is accepted or that peering replaces transit. PeeringDB is valuable precisely when used for what it is: a disclosure layer that can be checked against a detailed design, rather than a substitute for that design.

Housing is a separate operational proposition

Housing brings the physical layer to the foreground. Cloud Temple describes shared or dedicated racks, dual electrical chains, meet-me-room connectivity and on-site support. Each feature can matter to a customer placing equipment in a facility. Yet the same page's non-SecNumCloud-zone warning establishes that the offer must not inherit the qualification of a different service merely because it appears in the same portfolio.

The physical responsibility split is also different from IaaS. With housing, the customer may own or control equipment and remain responsible for hardware lifecycle, system configuration and the applications running on it, while Cloud Temple supplies space and specified site services. The exact split is contractual; the public page does not settle every duty. On-site support can range across many possible tasks, and the marketing term alone does not establish response time, authorization, spare-parts availability or successful repair.

Dual electrical chains are a design feature, not proof of end-to-end power independence. The benefit depends on how the customer's equipment is connected and on shared dependencies beyond the short description. Meet-me-room connectivity creates options for interconnection but does not prove that a customer ordered diverse carriers or physically separate paths. A shared or dedicated rack designation says something about space, not about the ownership of the wider facility.

This product therefore deserves its own evidence pack: the named site and operator, space allocation, power design, access procedure, support scope, cross-connects, customer equipment inventory and incident responsibilities. None of those details should be invented from the web page or from PeeringDB. The public material establishes an offer and a candid qualification boundary. A buyer's private documents must establish the purchased implementation.

Compliance labels need a workload-level join

The compliance page presents a substantial assurance surface. SecNumCloud 3.2 scopes sit alongside HDS, ISO 27001, C5 and related material, while the ANSSI decision independently names IAAS - SECURE TEMPLE. For procurement teams, that collection is valuable because it supplies multiple routes into due diligence. It is also where scope errors become easiest to make.

A label can answer only the question it was designed and scoped to answer. A management-system certificate does not automatically certify every technical outcome. A health-data hosting status does not make every workload compliant without the appropriate service and customer configuration. A cloud assurance qualification tied to a named IaaS does not flow into housing that the provider itself identifies as outside the SecNumCloud zone. Even closely related platform services need their exact scope confirmed.

The missing join is between assurance artifact and deployed workload. A useful record would identify the service name, version or option, applicable zone, customer architecture, shared-responsibility controls, evidence period and any excluded component. It would then map each requirement to the provider, the customer or a third party. That is more demanding than collecting certificates, but it prevents a familiar failure: evidence that is authentic and current yet irrelevant to the component being assessed.

Cloud Temple's public specificity makes this mapping possible in principle. The company distinguishes IaaS Secure Temple, PaaS OpenShift, Object Storage, Private Backbone and Housing in its materials. The buyer should preserve those distinctions rather than replacing them with a single vendor row marked "certified." The result is not scepticism for its own sake. It is a more accurate account of where assurance exists and where additional proof is needed.

Confidential evidence is part of the proof chain

Cloud Temple says detailed controls, supplier certificates and ISAE 3402 material may be available to customers under confidentiality. That creates a rational division between public evidence and customer diligence. Public pages can establish that certain services, controls and assurance artifacts exist. Sensitive reports and supplier documents may provide the detail needed to test scope, exceptions and dependencies without placing operational information on the open web.

Confidentiality does not weaken evidence merely because outside readers cannot inspect it. It changes who can verify the claim and under what conditions. A customer relying on non-public material should record the document title, issuer, covered period, scope, exceptions and review date, along with who evaluated it. The conclusion should be no broader than the evidence. "Reviewed under confidentiality" is useful only if the review is specific enough to be repeated and challenged.

Supplier certificates are particularly important where a Cloud Temple service depends on a third-party facility or component. The provider may remain the contractual counterparty while assurance for one layer comes from another organization. A certificate can help, but it still needs to be connected to the actual supplier, site, service and period. An unrelated or expired artifact does not close the chain.

The public record therefore has an intentional edge. It tells a researcher enough to identify where stronger documents should exist, but it cannot prove their contents. This article does not infer supplier performance, audit findings or hidden controls from the statement that material is available. It treats availability under confidentiality as a due-diligence path that a qualified customer can pursue.

Third-party dependencies must remain visible

Cloud portfolios often present one commercial interface over several operating layers. The customer may contract with Cloud Temple while a facility operator supplies the building environment, an exchange supports interconnection, a carrier delivers a circuit and the customer itself controls security equipment or topology. The public sources identify possible places and service features, but they do not fully enumerate or allocate every dependency.

That gap matters because responsibility and control are not the same thing. Cloud Temple may accept contractual responsibility for a service outcome while relying on suppliers for parts of delivery. Alternatively, a circuit or customer-controlled device may sit outside the provider's obligation. The only dependable way to tell is to follow the service schedule, supplier evidence and architecture handoffs. A PeeringDB facility entry or product-page reference cannot allocate liability on its own.

Facility ownership is a clear example. The directory lists DATA4, Digital Realty, Equinix and Telehouse, but the listing does not show that Cloud Temple owns any of those facilities. It also does not identify what product is available at each place. Treating all listed sites as a uniform Cloud Temple estate would overstate both property control and service reach.

The operational response is to keep a dependency register at product level. For each critical component, it should identify the delivering party, the Cloud Temple obligation, the customer's obligation, evidence of assurance, notice arrangements and the fallback if the dependency changes. This is especially important where a qualified platform meets non-qualified housing or customer-selected connectivity. The handoff may be entirely workable, but it must be designed and evidenced rather than hidden by the convenience of one provider name.

Hosting economics cannot be read from one price feature

The public material contains features with direct economic implications. Object Storage is presented without egress charges. Private Backbone offers external or dedicated circuits at stated 1 or 10 Gbps rates as product options. Housing introduces rack space, power, interconnection and on-site support. IaaS products combine compute, network, storage and backup in different ways. These choices shift cost between bundled service, customer labour and third-party dependencies.

No-egress pricing is the clearest example of why one attractive term should not stand in for total cost. Removing a transfer charge can make routine movement or eventual migration less expensive. The actual exit budget may still include engineering, destination service, temporary duplication, integrity checking, application change and sufficient connectivity. Object Lock can add timing constraints. The public evidence supports the advertised absence of egress charges, not a guarantee of costless or immediate departure.

Dedicated infrastructure creates another trade-off. It may give a buyer clearer resource boundaries or performance planning, but the economics depend on ordered capacity, term, utilisation and included operations. A public 99.99% availability statement or recovery target does not reveal the financial remedy, exclusions or business value of downtime. Those belong in the contract and in the customer's own impact model.

Housing can move hardware choice and lifecycle responsibility toward the customer, while managed cloud can place more platform work with the provider. Neither is inherently cheaper in every case. The meaningful comparison includes staff time, spares, migration effort, assurance work, cross-connects, backup testing and the cost of meeting the required control scope. Cloud Temple's portfolio gives customers several ways to assemble infrastructure. Its public pages do not prove which combination is economically best for a particular workload.

Portability has to be rehearsed, not presumed

Object Storage supplies the portfolio's most explicit portability vocabulary through S3 compatibility and no egress charges. VMware and Xen environments, backups, network allocations and housing equipment create other movement questions, even where the pages do not make broad exit promises. Together, they show that exit is not one action. Data, machines, configuration, addresses, security policy, physical assets and contracts may each follow a different path.

A credible plan starts with what must move and what can be rebuilt. Stored entities may be copied through a compatible interface, subject to retention and Object Lock constraints. Virtual workloads may require images, application data, keys, network rules and validation in a destination environment. Customer equipment in housing may require authorized physical access, logistics and replacement connectivity. Public addresses and routes require a plan consistent with the actual allocation and contractual control; AS33930 does not tell an outside reader what any customer may take away.

The plan also needs a clock. Recovery objectives are not exit objectives. Asynchronous replication is not a migration schedule. A 1 or 10 Gbps circuit option is not proof of available transfer throughput. The duration has to be estimated from real data volume, selected paths, destination readiness, retention constraints and operational windows. Testing a representative extraction can turn those assumptions into evidence.

Finally, responsibilities must persist through termination. Who maintains source access, produces exports, answers integrity questions, removes retained copies when allowed and supports a failed transfer? What happens if a qualification scope, supplier arrangement or product option changes before the move? The public sources do not answer those customer-specific questions, so no universal exit outcome can be claimed. They do provide enough product detail to make an exit schedule concrete before dependency becomes urgent.

Contract evidence should mirror the architecture

The architecture described across Cloud Temple's pages is modular. Contract evidence should be equally modular. A master agreement may identify CLOUD TEMPLE as the counterparty, but service schedules should preserve the distinctions among qualified IaaS, OpenShift, object storage, backbone connectivity and housing. Otherwise, a precise public qualification can become vague at the moment when a customer needs to enforce it.

For each service, the contract record should capture the ordered option, location or zone where relevant, stated service levels, measurement point, exclusions, support boundary and change-notification duties. Numerical claims deserve exact treatment. The VMware page's 15-minute RPO, sub-four-hour RTO and 99.99% availability should be checked against the binding terms for the purchased configuration. The public page alone does not show remedies or prove performance.

Supplier evidence belongs beside those schedules. If a facility or circuit is material, the record should identify the party responsible to the customer and the evidence available for the underlying layer. If Cloud Temple provides on-site support in housing, the permitted tasks and response commitments should be explicit. If the customer controls topology or security equipment on Private Backbone, change and incident duties should not be assigned to the provider by assumption.

This mirroring makes change manageable. When a service, zone, supplier or assurance status changes, the customer can identify affected workloads and controls rather than reopening an undifferentiated vendor assessment. It also keeps the non-SecNumCloud housing boundary visible next to qualified services. The goal is not a larger contract for its own sake; it is an evidence structure that follows the same boundaries as the system being operated.

A practical evidence matrix for buyers

Cloud Temple's disclosures support a compact set of conclusions, each paired with an explicit limit. The matrix below is not a verdict on any private customer design. It shows how public evidence can be converted into questions without crossing the source boundary.

Publicly visible claim	What it supports	What still needs customer-specific proof
ANSSI names `IAAS - SECURE TEMPLE` as qualified IaaS supplied by CLOUD TEMPLE	A defined qualified service and assurance period	Exact purchased service, zone, current applicability, configuration and workload mapping
Cloud Temple presents SecNumCloud scopes and HDS, ISO 27001, C5 and related material	A route to multiple assurance artifacts	Scope, period, exclusions and relevance of each artifact to the deployed component
VMware IaaS states multi-zone replication, 15-minute RPO, sub-four-hour RTO and 99.99% availability	Provider-published design and service targets	Binding terms, selected architecture, test results, actual SLA and recovery outcomes
OpenSource IaaS describes two-host availability, live migration and backups across three zones	Published platform mechanisms	Workload placement, application consistency, restore testing and customer duties
Object Storage is presented as qualified, S3-compatible, three-zone replicated and without egress charges	Published storage, interface, replication and pricing features	Used API surface, retention settings, transfer time, destination cost and tested exit
Private Backbone offers VPLS, addresses, anti-DDoS, VLANs and 1/10 Gbps circuits	A configurable provider network service	Ordered capacity, complete path, customer topology, security policy and headroom
RDAP, RIPEstat and PeeringDB expose AS33930, announcements and interconnection listings	Public network identity and disclosure	Traffic, route diversity, customer reachability, capacity, supplier roles and failover
Housing describes racks, power chains, connectivity and support in a non-SecNumCloud zone	A distinct physical-hosting offer and explicit qualification boundary	Site, operator, equipment, support scope, electrical path, cross-connects and contract

The discipline is the pairing. The left side prevents a needlessly dismissive assessment: there is substantial, checkable information here. The right side prevents overclaiming: none of the records reveals a complete customer architecture or its observed outcomes. A buyer can ask Cloud Temple for focused evidence because the public material already identifies the product and control vocabulary.

The same matrix can become an operating record. Add the service owner, evidence date, test result and next review date. Link each row to the workloads that depend on it. Where evidence is confidential, record the review rather than exposing the document. Where the customer controls the mechanism, assign an internal owner. In that form, qualification becomes one component of continuing assurance rather than a procurement badge that fades from view after signing.

The strongest conclusion is deliberately bounded

Cloud Temple has a more inspectable public surface than many infrastructure providers. The legal identity can be anchored to CLOUD TEMPLE, SIREN 825400336 and the Puteaux address. ANSSI names a specific qualified IaaS. Product pages describe virtualisation, storage, backup, replication, network and housing mechanisms. AS33930, RIPEstat and PeeringDB expose part of the public network footprint. The compliance page points customers toward deeper evidence under confidentiality.

The sources are strongest when they are allowed to remain different. A qualification decision proves something different from a product specification. A routing observation proves something different from a facility directory entry. A stated recovery target proves something different from a completed recovery. A non-SecNumCloud housing disclosure does not cancel the value of qualified IaaS; it identifies where that value stops carrying automatically.

That is why product-by-product responsibility proof is the central requirement. A customer needs to know which Cloud Temple service is being used, which assurance scope applies, how it was configured, which dependencies sit outside it, who operates each control and what the contract says when something changes or fails. The answer may be robust. It simply cannot be derived from a portfolio label alone.

The most credible reading of the public record is neither blanket endorsement nor blanket doubt. Cloud Temple discloses qualified services, detailed product features and a visible network identity, while also publishing a clear exception for housing. Buyers should use that candour to demand matching precision in architecture, evidence and contracts. The result would be a defensible chain from named service to deployed workload, with uncertainty recorded at every handoff rather than concealed beneath the strongest badge in the portfolio.

Cloud Temple's qualified services still need product-by-product responsibility proof