STERLY and the Data-Centre Records Behind Turkish Cyber-Security Services

Summary

• STERLY presents itself as a Turkish data-centre, cloud, software and cyber-security provider, but the strongest public evidence sits in its operational records: RIPE ASN registration, PeeringDB contacts, DNS, mail posture, facility-presence claims, account-portal links and support-role separation.
• The current routing picture is materially narrower and more auditable than the marketing surface: AS204843 is visible in RIPEstat as announced, with one IPv4 /24 and fifteen IPv6 /29s in the frozen evidence window, while PeeringDB self-reported prefix and traffic fields need to be treated as operator-maintained claims rather than verified capacity.
• STERLY's useful due-diligence question is not whether it has a broad service list. It is whether the company can keep account state, route policy, contact roles, backup boundaries, locality promises and incident-support records synchronized under repeated operational pressure.

STERLY is the kind of company that can disappear inside its own label if the reader is not careful. The legal name, STERLY Veri Merkezi Yazilim ve Siber Guvenlik Hizmetleri A.S., already contains the promise: data centre, software, cyber-security services. The public website adds cloud servers, virtual data centres, business continuity, hosting, domain services, corporate mail, backup, VPN, proxy, firewall, web application firewall, penetration testing and SSL. The company page says it serves public institutions, private companies, financial institutions and fintech customers.

The home page talks about Turkish cloud identity, round-the-clock service, dark-fiber reach and a data-centre network. That is a large envelope for one provider.

The problem with that kind of envelope is not that it is false. The problem is that it is too broad to be useful by itself. Every regional cloud and security provider wants to be read as complete. Every provider wants the buyer to join the dots from "data centre" to "resilience", from "cyber-security" to "incident response", from "cloud portal" to "automation", and from "local office" to "local accountability". Those links are plausible, but they are not automatic. They have to be tested through records.

STERLY's public evidence is therefore more interesting than its service menu. The company has a RIPE autonomous system, AS204843. RIPE RDAP records tie that ASN to the long STERLY legal name and to the organisation handle ORG-SVMY1-RIPE. RIPEstat showed the ASN as announced in the frozen evidence window. The announced-prefix view showed one IPv4 route, 185.254.54.0/24, and fifteen IPv6 /29s visible from late June through July 13, 2026. RPKI validation for the IPv4 /24 returned valid with origin AS204843 and max length /24.

PeeringDB lists the network as an enterprise network with a website, a route-set label, public Abuse, NOC, Sales and Technical contacts, and a looking-glass URL. DNS places the public web and cloud account hostnames behind Cloudflare. Mail records point at Microsoft 365 protection with SPF configured. These are not glamorous facts, but they are the sort of facts that decide whether a service boundary can be inspected.

The public record also contains friction. STERLY's website claims a broad data-centre and cloud footprint, while the BGP record is small enough to audit by hand. PeeringDB lists an IPv4 Prefixes value of 500 and a self-reported traffic band, yet RIPEstat and Hurricane Electric's opened AS page saw one originated IPv4 prefix and fifteen originated IPv6 prefixes. PeeringDB lists facility associations in Turkey, Germany and Bulgaria, but the organisation profile itself does not establish that STERLY owns those facilities. The company site says there are multiple offices and many service areas; business-directory and registry records show different Bursa and Istanbul address references that need to be reconciled. A PeeringDB looking-glass URL exists, but the frozen DNS check did not return an A record for lg.sterly.com.tr from this resolver. None of these points proves failure. Together, they describe the operating question.

For a buyer, STERLY matters if it can make Turkish locality and human support behave like infrastructure, not if it can list the same cloud nouns as every larger rival. A domestic provider can be attractive because the support path is closer, the legal and language context is simpler, the migration conversation can be direct, and the service boundary can be shaped around local compliance or finance-sector expectations. The trade-off is that the buyer often gets fewer public dashboards, fewer third-party analyst reports and less independent performance data than with a hyperscale cloud.

The smaller provider has to substitute record discipline for brand gravity. It has to show that the route objects, account portal, abuse contacts, backup claims, data-location claims and support inboxes are all part of the same governed system.

That is why AS204843 is not a side detail. It is one of the few public machine-readable anchors in the STERLY file. An autonomous system is not a product, and a route is not a guarantee. But if a provider is selling cloud, data-centre or security services, the route layer shows whether there is an attributable network identity beneath the brand. In STERLY's case, the ASN was registered in June 2022 and changed in March 2026 in the RIPE RDAP record. The holder string uses the long STERLY legal name. The record includes organisation, administrative, technical and abuse references.

RIPEstat's overview shows the ASN as announced at the query time. That is the difference between a website-only hosting brand and a company with a visible network-resource footprint.

The scale of that footprint should not be inflated. One active IPv4 /24 is not a national carrier. Fifteen IPv6 /29 announcements are technically large in address space, but IPv6 address arithmetic should not be confused with operating density, customer count or traffic. The more sober reading is that STERLY has a visible autonomous-system identity, a current routing presence, and enough address-resource complexity to require proper route governance.

It is not possible from the public evidence to conclude how many customer workloads use those prefixes, how much traffic crosses the network, what redundancy exists behind each route, or how the provider handles failover. Those questions need customer-facing evidence that was not public in the frozen pack.

The RPKI signal is still meaningful. The IPv4 prefix 185.254.54.0/24 validated as a correct origin for AS204843 in the RIPEstat RPKI check. That matters because route-origin validation is one of the basic controls that can reduce accidental or malicious mis-origination. It does not prove that every route policy is perfect, and it does not prove that the IPv6 prefixes have the same validation posture. But it does show that at least one visible public route is not simply floating without origin validation.

In a service where cloud servers, logs and recovery systems may sit behind provider addressing, that kind of hygiene is part of the evidence surface.

The routing-consistency evidence is more revealing than a headline prefix count. RIPEstat's consistency view showed the active prefixes in both BGP and whois or IRR, but it also showed three AFRINIC IRR prefixes present in whois but not visible in BGP at the query time. It also showed import/export policy records that did not fully match observed BGP peers. That does not mean customers are affected. It does mean the public routing file contains stale or dormant edges. For a company selling operational reliability, this is not a minor clerical question.

IRR objects, import policy and export policy are part of the set of documents that other networks, automated filters and incident responders may consult. If those entities become historical residue, the provider may still route perfectly in practice, but the public evidence becomes harder to trust.

This is one of STERLY's central due-diligence points: the company should be judged on record freshness as much as on service breadth. A dormant route object is not the same as an outage, but it creates ambiguity during troubleshooting. A peer visible in BGP but absent from the policy record does not necessarily mean bad routing, but it raises the question of how quickly public policy records follow operational changes. A PeeringDB looking-glass URL is useful only if it resolves and responds when a network operator needs it. A support contact is meaningful only if the role still maps to a monitored queue.

These are the unglamorous parts of cloud reliability.

PeeringDB sharpens the same picture. The network profile lists public contacts for Abuse, NOC, Sales and Technical roles. All use the same phone number and separate role-based email addresses. That is a positive sign: the company has at least separated public published contact points by function, rather than leaving every operational issue at a generic sales inbox. For abuse handling, that separation matters. A customer receiving complaints about malicious traffic, phishing, spam, command-and-control callbacks or compromised virtual machines needs the provider to distinguish incident intake from commercial inquiry.

For cloud operations, the NOC contact matters because routes, datacentre access, mitigation and escalation are rarely solved by the same person who handles quotes.

The public-contact record is not the same as a service-level test. There is no public evidence here showing response time, after-hours staffing, ticket escalation, incident reports or mean time to repair. The official site says the company works around the clock and has a 37-person team. LinkedIn's public profile places the company in the 11-50 employee band, which is directionally consistent with that claim. But neither record proves the distribution of support labour across network operations, cloud support, sales, security testing, account management and incident response.

A 37-person team can be excellent if responsibilities are crisp, tools are automated and on-call is disciplined. It can also become overloaded if each support event depends on a handful of senior engineers.

Local-support labour is therefore not a soft human-resources detail. It is the control plane for a regional provider. STERLY's pitch is strongest when a customer needs Turkish-language support, local account handling, and a provider that can speak directly about Bursa, Istanbul, Turkish networks and domestic business practices. The advantage is proximity. The risk is concentration.

If sales, technical support, abuse, account billing and incident recovery are all attached to a small team and a shared phone number, the buyer should ask how tickets are triaged, how emergencies pre-empt routine requests, how responsibilities are separated, and what happens when key staff are unavailable.

The locality story is also layered. The official contact page gives a Bursa/Nilufer office address. The RIPE organisation record gives a Bursa address at Konak Mahallesi, Baris Street, Ofis Arti Blok, while a RIPE person or role record also references an Umraniye, Istanbul address. A business-directory page, drawing from Bursa Chamber of Commerce material, places the company in Bursa/Osmangazi and categorises it under computer programming and consultancy with a NACE software activity. The official about page says the company is headquartered in Istanbul and has offices in Ankara, Bursa, Izmir and Istanbul.

PeeringDB facility associations include Istanbul, Denizli, Adana, Bursa, Frankfurt and Sofia-area entries.

Those records do not tell a simple story of one building, one cloud and one jurisdiction. They tell a more modern regional-provider story: a legal and support presence in Turkey, route and contact records in RIPE, cloud and web surfaces behind Cloudflare, mail via Microsoft 365, and interconnection or facility associations that extend beyond one city. That can be good. It may give customers more options for connectivity and continuity. But it also means that "local" cannot be treated as a single word.

Local support, local contracting, local data storage, local network exit, local backup, local disaster recovery and local legal process are different claims. They need different evidence.

STERLY's website makes locality central by presenting itself as a Turkish data-centre and cloud operator. It references multiple data-centre locations and white-space capacity. It also names major technology and network brands as partners or operators. Those statements can help frame a buyer conversation, but they should not be imported directly into a risk model. A logo list does not prove a current support entitlement. A facility association does not prove ownership.

A statement about data-centre capacity does not prove rack availability, power redundancy, cooling design, fire suppression, access-control regime, backup topology or customer isolation. The practical buyer should ask for the documents that convert locality from a theme into a control.

For example, if a Turkish fintech is considering STERLY for a backup, log retention or virtual-data-centre workload, the important question is not just where the company is based. It is where the data will sit at rest, where replicas will sit, who can access the account, how support staff authenticate, how recovery is tested, whether logs leave Turkey, whether disaster-recovery images use the same provider account, and whether the provider can produce audit evidence without improvising. STERLY's public site says the company offers backup and recovery, network security and cloud computing.

The public record does not show backup test results, retention-policy controls or customer-specific recovery objectives. That is exactly the gap the procurement process should close.

The account surface deserves particular attention. The public website routes users toward cloud.sterly.com.tr for login, registration and help documents. DNS for the cloud hostname resolved to the same Cloudflare A records as the main domain in the frozen check. That suggests STERLY's public web and account entry points are fronted through the same protection layer, at least from a DNS perspective. Mail records use Microsoft 365 protection, and SPF references Microsoft's protection domain. These choices are not unusual. They are also not incidental. A regional cloud provider's account portal and support mail are part of its security perimeter. If the portal controls server provisioning, backup restore, billing, identities or support tickets, then account-state drift can become a service incident.

Account-state drift is a quiet failure mode. It happens when billing status, identity permissions, support entitlements, product provisioning and network policy no longer describe the same customer. One system thinks a virtual server is active; another thinks the subscription is suspended. One contact can request a restore; another contact is still in the address book after leaving the customer. A support ticket authorises a firewall change; the portal role does not. A backup job succeeds, but the account does not show a recoverable image. The public evidence does not say whether STERLY has these problems.

It says the company offers enough account-linked services that the buyer must ask how those records are reconciled.

This is where enterprise-software automation becomes the real product. STERLY's home page says customers can increase or decrease resources and choose configurations through a portal. If true in production, that is not simply convenience. It means STERLY is operating a resource and entitlement system that has to translate account choices into compute allocation, storage, network policy, billing, monitoring and support visibility. The company name includes "software" for a reason: the cloud service is not only servers in a room.

It is the software layer that lets staff and customers change those servers repeatedly without losing track of authority.

The risk is that automation can make stale records faster. A manual provider may be slow, but a bad manual process often fails visibly. A portal-driven provider can propagate a wrong state across products. If a user role is too broad, it can touch too much. If a product catalogue is not tied to real capacity, it can sell configurations support cannot sustain. If a firewall rule is applied outside the portal, the portal may lie. If backup retention is changed in one console but not reflected in the customer view, a restore assumption can survive until the moment of crisis.

For STERLY, the public value of the portal claim depends on record synchronization, not on the existence of a login page.

The cyber-security services should be read with the same discipline. The website lists firewall, WAF, penetration testing, SSL, VPN and proxy services. Those are recognisable categories, but they can mean very different operating models. A firewall service may be a managed appliance, a rule-change workflow, a one-time configuration, or a resale of another vendor's feature. A WAF service may include tuning and alert review, or it may be a product SKU. Penetration testing may be a structured assessment with reporting and retest, or a narrower scan. VPN may be a private-access service, a hosted gateway or a simple product option.

Public text alone cannot resolve those meanings.

That ambiguity is important because security services carry a higher evidence burden than compute. A virtual server can be measured by uptime, latency, performance and support response. A security service also has to explain scope, responsibility and evidence. Who watches the alerts? Who approves rule changes? Who documents exceptions? Who owns false positives? Who performs retesting? How are vulnerabilities disclosed? How are incident logs retained? How are abuse complaints mapped to customers? What happens when a security service and a hosting service point at each other during an incident?

STERLY's public contact split between Abuse, NOC and Technical roles is a good start, but the operational contract has to define where each role stops.

The abuse channel is especially relevant for a provider with cloud, hosting and network services. Any infrastructure company that rents servers or hosts applications will eventually encounter compromised accounts, phishing pages, spam, brute-force traffic, scanning or command-and-control abuse. The public PeeringDB abuse contact and RIPE abuse role give outsiders a place to report. The buyer's question is what happens after a report arrives. Does STERLY notify the customer? Suspend the workload? Provide packet or log evidence? Preserve data for investigation? Offer remediation support? Escalate only after repeated complaints?

Without that process, an abuse inbox is just an address. With a disciplined process, it becomes part of the provider's security posture.

There is also a commercial reason to study these records. Regional providers compete with hyperscale clouds, national carriers, managed-service firms and self-managed infrastructure. STERLY's likely value proposition is not lowest global price or deepest service catalogue. It is the combination of local Turkish presence, data-centre and cloud packaging, security add-ons, account support, migration help, and enough network identity to be inspected. That can justify a contract when the buyer needs human support and a domestic operating conversation more than endless product breadth.

It can fail when the buyer expects hyperscale observability, published SLAs, instant global redundancy or extensive third-party certifications.

Migration cost is often the hidden commercial lever. A customer moving from self-managed servers to STERLY is not only buying compute. It is moving DNS, IP allowlists, certificates, mail relay assumptions, backups, monitoring, firewall policy, account roles, procurement, incident contacts and staff habits. A local provider can reduce that cost by doing hands-on onboarding and speaking the customer's operational language. It can increase that cost if product boundaries are unclear or if records are not exportable.

Buyers should ask whether they can leave cleanly: export images, retrieve backups, document firewall rules, move IP dependencies, close account roles and preserve incident history.

The routing record suggests another migration issue: provider addressing. If a customer builds allowlists or partner integrations around STERLY-originated IP space, the customer's own downstream dependencies begin to trust that address plan. The public evidence shows one IPv4 /24 and a set of IPv6 /29 announcements in the current window. That may be enough for some workloads, but it also means IPv4 space is a scarce and visible resource. Buyers should ask whether they receive dedicated addresses, shared NAT, provider-managed WAF addresses, or customer-routed prefixes.

They should ask how RPKI, reverse DNS, abuse history and blacklisting are managed. They should not assume that "cloud server" means the same network behaviour as a hyperscale virtual machine.

The PeeringDB facility associations are useful for another reason: they show that STERLY wants to be discoverable in an interconnection context. The listed locations include Turkish facilities in Istanbul, Denizli, Adana, Esenyurt and Bursa, plus Frankfurt and Bulgaria entries. The network also has a listed operational attachment at 4b42 Internet Exchange Point in Switzerland over IPv6 with 1G speed and no route-server peer flag. This is not a dense global peering mesh. It is a set of public signals that STERLY participates in the interconnection world and wants other networks to know where it can be found.

That distinction matters. Facility presence is not the same as owned data-centre capacity, but it can still matter operationally. It may indicate where the network can interconnect, where capacity can be arranged, or where the provider expects peers and carriers to find it. If those records are current, they make STERLY easier to evaluate. If they are stale, they become another source of operational ambiguity. The June 2023 update dates on several PeeringDB fields mean the buyer should ask for confirmation rather than assume the 2026 service footprint matches every listed association.

The public website's data-centre capacity language raises a similar caution. It includes figures for white-space capacity and location-level claims, but the extracted text repeats and appears inconsistent in places. A generous reading is that a designed website card or carousel was flattened oddly by indexing. A stricter reading is that capacity presentation is not clean enough to use as evidence. Either way, the editorial conclusion is the same: repeatable service operations require source documents beyond marketing copy.

A serious buyer should request current facility list, certification status, power and cooling redundancy, connectivity carriers, backup locations, access-control procedures, maintenance windows and incident-reporting practice.

STERLY's official about page states a broader international service geography, including countries in the Middle East and Europe. That claim fits the company's ambition, but public routing and registry evidence cannot confirm customer delivery in each named market. The article therefore treats "Global" as the region for publication because the assignment and service claims are cross-border, while the evidence emphasis remains Turkey-centred. The company is Turkish in legal and operational identity, and the locality evidence is strongest around Bursa and Istanbul.

Cross-border claims should be handled as sales and service statements until they are backed by customer, facility, route, regulatory or partner evidence.

This bounded reading is not hostile to STERLY. It is the fair way to evaluate a provider whose value depends on trust. Smaller infrastructure companies often do important work that is not visible in public filings. They may solve migration problems faster than larger rivals. They may answer the phone. They may know the local regulator, bank audit expectations and customer language. They may be able to build a practical continuity plan around a client's actual constraints, rather than forcing the client into a global template. The public record does not disprove any of that.

It simply says the proof has to be obtained through operating evidence.

The buyer's diligence pack should therefore be concrete. First, ask STERLY to reconcile public routing records: current originated prefixes, RPKI coverage, IRR objects, import/export policy, upstreams, peers and looking-glass availability. Second, ask for account-governance evidence: role model, multi-factor authentication, approval workflow, account suspension rules, billing-state reconciliation, support-ticket linkage and audit logs. Third, ask for data-locality evidence: where production data, backups, logs and support attachments sit, and how cross-border replication is controlled.

Fourth, ask for security-service boundaries: what is monitored, what is configured, what is tested, what is reported and what remains the customer's job. Fifth, ask for recovery proof: last restore test, recovery time objective, recovery point objective, backup immutability and separation from the primary account.

The same diligence applies to incident support. STERLY's public contacts are a map, not a guarantee. Buyers should test the map before they need it. Send a non-emergency support request and measure routing. Ask how the NOC differs from technical support. Ask whether abuse reports create customer tickets. Ask whether out-of-hours response uses the same queue. Ask how incident updates are delivered during a portal outage. Ask whether telephone support can authenticate emergency changes without weakening account security. Ask who can approve a firewall rollback or restore request when the named account owner is unreachable.

There is one subtle positive in the record: STERLY's public technical footprint is small enough to be questioned. That sounds like faint praise, but it is valuable. Some providers wrap themselves in vast, vague claims and leave no precise handle for evaluation. STERLY has handles: AS204843, ORG-SVMY1-RIPE, RS-STERLY-AS, role contacts, cloud hostnames, mail records, office addresses and PeeringDB locations. A customer can ask about each one. A provider that can answer with current documents, screenshots, monitoring exports and policy statements would turn the public record into an advantage. A provider that cannot answer would reveal where the brand has outrun the operating system.

The known failure modes in this case are therefore clear. Dormant-route ambiguity appears when whois or IRR records describe prefixes or peers that are not present in observed BGP. Stale registry records appear when addresses, contacts, policy entities or facility associations age without refresh. Outage opacity appears when a portal, looking glass or status route cannot be independently checked. Account-state drift appears when billing, roles, support and infrastructure do not match. Backup gaps appear when restore claims are not backed by test evidence. Support backlog appears when a small team carries too many categories of work.

Unsupported uptime claims appear when marketing says round-the-clock service but does not show incident history, redundancy design or SLA enforcement.

The public evidence does not show that STERLY is suffering from those failures. It shows why those are the right tests. The difference matters. A responsible article should not turn a DNS timeout from one environment into a public outage allegation. It should not turn a self-reported PeeringDB traffic band into a verified traffic statistic. It should not turn a logo list into contractual proof. It should not turn one valid RPKI check into a blanket statement about all routes. But it can say that STERLY's buyer risk lives in the synchronization between these records.

This is also why the company's software layer may be more important than its visible network size. A regional provider with a modest ASN can still be highly valuable if its internal systems keep customer resources, backup states, firewall rules, security findings, invoices and support tickets in one coherent operating model. Conversely, a provider with impressive facility language can become risky if every product line has a different truth. For STERLY, the website's promise of portal-based resource changes and product management is the hinge. That portal has to be more than a storefront.

It has to be the authoritative interface between customer intent and infrastructure state.

There is a practical way to read STERLY's place in the market. It is not trying to be AWS, Microsoft Azure or Google Cloud. It is not presented as a pure managed-security consultancy either. It sits in the middle: a Turkish infrastructure and cloud services provider with security add-ons, account support, data-centre language and an attributable network identity. That middle can be commercially durable because many organisations do not want to assemble every piece themselves. They want one provider to host servers, manage access, help with security, handle backups and answer during incidents.

The danger is that "one provider" becomes "one opaque dependency" unless the records stay visible.

The Turkish context strengthens the case for record discipline. Local businesses, public institutions and financial organisations often care about where data is handled, who can be reached, and how documents are produced for audits or disputes. A provider that can show local offices, role contacts, controlled data placement and repeatable recovery has a genuine advantage. A provider that relies only on broad assurances will struggle when auditors ask for evidence. STERLY's public materials point toward the right areas, but the public materials themselves are not enough. The procurement file has to convert them into verifiable commitments.

The same point applies inside the customer organisation. A buyer cannot outsource every record just because it hires a cloud or security provider. If STERLY hosts a workload, the customer still needs its own inventory of systems, owners, access rights, backups, approved contacts and dependency chains. If STERLY performs a security test, the customer still needs to know what scope was tested, which findings were remediated, which exceptions were accepted and which systems remain outside the engagement. If STERLY manages a firewall or WAF boundary, the customer still needs an internal record of why key rules exist.

Provider discipline and customer discipline have to meet. Otherwise the contract creates two partial truths, and neither side can reconstruct the service during an incident.

This is where STERLY's local-support promise can become more valuable than a purely automated cloud workflow. A local team can help translate operational reality into usable records: who owns the server, why a route exists, how a firewall rule reached production, which backup should be restored, which contact can approve emergency access and which regulator or auditor will need evidence later. But that advantage only appears if support conversations leave a durable trail. Phone support may be faster than a portal in a crisis, yet the decision still has to land back in a ticket, account log or change record.

The best version of STERLY would treat local human support as a way to improve the record, not as a workaround for missing automation.

For existing customers, the immediate action is not necessarily to leave or renegotiate. It is to inventory dependencies. Which services are with STERLY? Which account owns them? Which staff can approve changes? Which IP addresses are allowlisted by partners? Which backups have been restored in a test? Which security services are active versus merely available? Which contact path is used for after-hours incidents? Which records would be needed to migrate away? A calm dependency inventory is cheaper than a crisis inventory. The public evidence suggests STERLY has enough moving parts that customers should maintain their own map.

For prospective customers, the commercial question is whether STERLY's reliability, locality, support and migration help justify its service boundary compared with alternatives or self-managed records. The answer could be yes for a company that values local language, Turkish business context, direct support and a bundled cloud-security offering. The answer could be no for a company that needs published global resilience metrics, highly automated compliance exports, many regions, broad marketplace integrations or extensive independent assurance.

The right choice depends less on the length of STERLY's service list than on the buyer's tolerance for evidence gaps.

The most constructive reading of STERLY is that it has enough public infrastructure evidence to deserve a serious evaluation, and enough record inconsistencies to make that evaluation necessary. The ASN is real. The route announcements are visible. The IPv4 route has a valid RPKI origin check. The company publishes role contacts. The website describes a substantial service mix. The locality evidence is real but plural. The interconnection records are specific but partly aged. The account and support surfaces are visible but untested. That is neither a warning label nor a clean bill of health.

It is an invitation to verify the operating record behind the name.

In the end, STERLY should not be assessed through the drama of a long legal title. It should be assessed through the quieter question of whether records stay fresh when work repeats: when a customer adds a server, changes a firewall rule, opens a support case, receives an abuse complaint, restores a backup, audits data location or migrates a workload. Data-centre services are not just rooms. Cyber-security services are not just product names. Cloud software is not just a portal. All three are record systems. STERLY's public record shows the outlines of such a system.

The buyer's job is to make the provider prove that the outlines hold under pressure.