The /24 That Left: Testing the Control Surface of 4Cloud Systems

Summary

• Public tax, business, domain and internet-registry records form a coherent identity bridge from Patryk Pazdro and the Polish tax number displayed by 4Cloud Systems to the exact RIPE member name “Patryk Pazdro trading as 4Cloud Systems,” its website and AS213539.
• AS213539 genuinely originated one IPv4 /24 for roughly nine months, but RIPE's current observation shows no announced IPv4 or IPv6 space. That change is not proof of an outage or business failure; it is evidence that the operator's practical value lies in arranging and changing third-party resources as much as in holding them.
• The company homepage claims a Warsaw point of presence, 600 Gbps of managed capacity, 99.95% availability, routing, colocation, CDN, automation and advertising-technology work. Public records corroborate a real network control surface, but do not independently establish the capacity figure, facility, service boundary, customer references, security posture or contractual service level.
• A buyer should keep cloud and carrier accounts, billing data, root recovery, source repositories, logs and export rights in the buyer's own name. 4Cloud Systems should receive narrowly scoped, time-bounded operating access and leave behind tested runbooks, change history, infrastructure definitions and an executable exit.

At 08:00, a route became the whole story

At 08:00 UTC on 14 February 2026, RIPE's Routing Information Service last observed the IPv4 block 93.88.202.0/24 being originated by AS213539. The current RIPE routing-status response records that last sighting, reports that none of its hundreds of IPv4 or IPv6 collector peers can now see the autonomous system, and counts zero currently announced addresses. A separate RIPE routing-history response traces the same /24 through repeated observation windows from May 2025 into February 2026. This was not merely a number reserved in a registry. For a time, it was a route on the public internet.

The route's next state is more instructive than its disappearance. A Hurricane Electric snapshot, updated on 13 February 2026, still showed 93.88.202.0/24 originated by AS213539, with the prefix registrant labelled “File-Hosting-Solutions-Patryk-Pazdro.” The live RIPE search for that same /24, accessed for this article, now identifies the netname as SprintCDN and contains a route object for AS206963 created on 14 February 2026. The public record therefore captures a handover: one origin stopped and another was authorised around the same date.

That sequence should not be embellished. It does not tell us why the block moved, who owned the underlying commercial contract, whether a customer project ended, whether a supplier changed, or whether any user suffered downtime. It does not prove that 4Cloud Systems has stopped all network work. An autonomous-system number can remain assigned while originating no routes, and a managed-services firm can operate customer networks that do not appear under its own number.

The sequence does prove something narrower and commercially useful: 4Cloud Systems acquired enough operational standing to register an autonomous system and make a /24 globally visible, and the address resource was not a permanently inseparable part of the firm.

That is the opening mechanism for understanding this business. A small infrastructure operator need not own concrete, generators, fibre routes or a fleet of servers to exercise consequential control. It can select an upstream, arrange address space, maintain route-policy records, change an origin, configure filtering, hold administrative credentials, operate deployment software and decide who receives an alert at three in the morning. Those permissions can determine whether a customer's service exists even when every physical asset and every large cloud account belongs to somebody else.

The /24 also supplies a useful antidote to marketing shorthand. “Capacity,” “point of presence,” “backbone” and “cloud” are not interchangeable. A public route demonstrates routing activity. It does not measure 600 Gbps. An exchange-port entry demonstrates a connection, not end-to-end service. A rack contract establishes access to space, not ownership of a facility. A cloud administrator role establishes authority over a tenant, not ownership of the provider's computers. Any assessment of 4Cloud Systems has to keep those layers separate.

The identity bridge is unusually testable

The assigned directory name is exact and slightly formal: Patryk Pazdro trading as 4Cloud Systems. Public evidence supports that wording through several independent joins.

First, 4Cloud Systems' own homepage gives the trading name, a Rzeszów address at Wincentego Pola 18, the Polish tax identifier 8652500342 and an email address on 4cloud.systems. Second, a point-in-time query to the European Commission's VIES service for PL8652500342 returned a valid VAT record in the name Patryk Pazdro at Wincentego Pola 18, 35-021 Rzeszów. VIES confirms the person, tax identifier and address; it does not by itself supply the 4Cloud trade name.

Third, a Polish business-data page explicitly sourced to the central register identifies 4Cloud Systems Patryk Pazdro as a sole proprietorship, gives the same tax number and address, records REGON 38749066500000 and dates the activity to 11 November 2020. Its listed activities span media advertising, telecommunications, information-technology services and hosting-related work. Business-activity codes show what an enterprise has registered to do; they are not proof of revenue, expertise, customers or current delivery. Here, their value is identity and scope, not performance.

Fourth, the authoritative internet registry makes the brand-to-network link explicit. The RIPE organisation record names “Patryk Pazdro trading as 4Cloud Systems,” classifies it as a local internet registry in Poland and gives the same Wincentego Pola address. The associated RIPE autonomous-system record ties ORG-PPTA5-RIPE to AS213539, whose registry name is MintCloudSystems. It was created on 21 January 2025 and contains declared import and export policies involving AS30058, AS6939 and AS9002. Those policy statements express intended routing relationships in the registry; observed routes are the separate test of what was actually visible.

Finally, RIPE's current list of members offering service in Poland includes the exact 4Cloud Systems trading name. An older RIPE member detail page still uses the earlier label “Patryk Pazdro trading as File & Hosting Solutions”, while an older Polish business listing for File & Hosting Solutions Patryk Pazdro carries the same tax identifier and REGON. These records support continuity of the same sole trader through a public-facing name change. They do not establish a precise legal effective date for every change, so the older and newer labels should not be treated as simultaneous product brands.

The domain history fits that sequence without defining it. The official .systems registry response for 4cloud.systems records registration on 19 August 2025 and the current Aftermarket Hosting name servers. A domain registered in 2025 does not make the business only a year old; the tax-linked activity dates to 2020 and the autonomous system predates the domain. It suggests that the present web identity arrived after the business and the network number.

This careful bridge matters because there are other businesses and products with similar “4Cloud” or “File & Hosting” names. None is imported into this analysis. A similarly named company, a social profile, an unrelated cloud product or an old legal entity cannot be assumed to be the assigned sole trader. The claims here stop at the tax-linked Polish enterprise, its proven domain, its RIPE organisation and the network resources directly joined to those identifiers.

The evidence supports network work, not infrastructure ownership

The company's homepage is specific enough to evaluate. It says engineers in Rzeszów operate from Warsaw; describes one point of presence called WAW-1; claims 600 Gbps of managed capacity and 99.95% availability; and offers network architecture, servers and colocation, remote hands, content delivery, software automation, programmatic-advertising integration and ISP uplink work. It promises dashboards, utilisation exports, versioned runbooks, an escalation matrix and direct engineer communication. It also describes the facility as “Tier I.”

Those are company claims. The routing history independently corroborates a narrower slice: there was a working public routing identity and one originated IPv4 prefix. The RIPE organisation record independently corroborates local-internet-registry status. They make the network proposition materially more credible than a generic consultancy landing page. They do not corroborate the stated throughput, continuous network availability, named facility, rack footprint, customer load, number of engineers, server inventory, CDN reach or advertising yield.

The current public network picture is smaller than the homepage language might lead a casual reader to assume. RIPE currently sees no announced prefixes. The PeeringDB response for AS213539, updated on 6 July 2026, identifies MintCloudSystems, the 4Cloud website and a “Content” network with global scope, but returns no current public-exchange or facility records. Its informational prefix counts are not the same as observed announcements and currently diverge from RIPE's zero-route view. Registry and directory fields can lag operations, contain planned values or reflect self-description; buyers should reconcile them with live route evidence rather than choose one convenient screen.

There is also a striking point about the public website. A current Hurricane Electric host view lists 4cloud.systems on 185.253.215.19, an address in a prefix originated by AS48707 and shared with many other domains. That means the marketing site is not presently served from AS213539. It does not mean the claimed operational estate is fictional. Sensible operators often keep a brochure site away from production, and shared hosting can be economical and isolated from customer work. It does mean the website cannot be used as a live demonstration of the firm's own network.

The same restraint applies to the vanished /24. Its route history proves operation, but the current assignment to SprintCDN suggests the address space was supplied, transferred or reassigned rather than permanently held as an enduring 4Cloud asset. The exact commercial mechanism is not public. A buyer should therefore ask whether any proposed addresses are provider-aggregatable space, portable assignments, customer-owned resources or temporary leases; who can create the route-origin authorisation; and what happens to addresses, reverse DNS and allowlists at termination.

“Managed capacity” is similarly broader than owned capacity. It may describe aggregate ports under management, customer links, contracted transit, CDN traffic, burst headroom or an engineering envelope. None of those interpretations is inherently improper, but they produce different risks. If 4Cloud merely administers a customer's carrier contracts, the customer may retain excellent portability. If 4Cloud resells a bundled service and holds all upstream agreements, the customer may have one invoice but less visibility and a harder exit.

If 600 Gbps is the sum of theoretical interfaces rather than measured customer traffic, it should not be compared with delivered throughput.

The public evidence therefore supports a real but bounded conclusion: Patryk Pazdro's enterprise has performed internet-numbering and routing work and publicly offers a wider systems practice. It does not support calling the firm a data-centre owner, hyperscale cloud, global carrier or proven 600 Gbps network. The distinction is not pedantic. It determines which assets can be audited, which supplier can repair a fault, and who still has leverage when the relationship ends.

4Cloud's product is the boundary between accounts

The most useful way to procure 4Cloud Systems is to draw three columns before discussing technology. The first contains things the customer must own. The second contains access that 4Cloud may operate. The third contains infrastructure and services belonging to carriers, facilities, software vendors and cloud providers.

Control area	Customer should own	4Cloud may operate under delegation	Third party actually supplies
Commercial authority	Master agreements, billing contacts, renewal decisions, budgets	Usage review, recommendations, approved orders	Cloud tenancy, transit, exchange port, rack, licences
Identity and recovery	Organisation owner, emergency recovery, identity provider, approval groups	Named operator roles, time-bounded elevation, service identities	Authentication service and management consoles
Configuration	Source repository, policy baseline, approved architecture, export copies	Infrastructure definitions, routing policy, deployment pipelines, dashboards	APIs, hypervisors, routers, platform features
Data and evidence	Encryption choices, retention rules, audit exports, backup ownership	Monitoring, backup jobs, incident collection, restore execution	Storage media, log services, backup platform
Network resources	Portable addresses where justified, domains, DNS approval, allowlists	Route objects, filtering, peering changes, DNS implementation	Address lessor, registry, upstream carrier, DNS host
Exit	Success criteria, replacement access, deletion instruction, acceptance sign-off	Documentation, credential removal, exports, knowledge transfer	Data egress, contract closure, port or circuit release

That map turns an ambiguous “managed cloud” engagement into a workflow.

The first stage is discovery. 4Cloud should inventory business services, data classes, dependencies, existing contracts, recovery objectives, traffic patterns and change windows. It should identify where a customer thinks it has redundancy but actually shares one identity provider, one DNS zone, one billing account, one physical path or one human approver. The output should be a customer-owned dependency map and decision record, not a slide that only the supplier can interpret.

The second stage is account and landing-zone design. If public clouds are involved, the customer creates the organisation and billing relationship in its own legal name. 4Cloud receives a dedicated role rather than the recovery owner credential. Separate production and non-production boundaries, logging destinations, budget alerts, policy controls and network connections are established before workloads move. If the work is colocation or transit, the same principle applies: customer and supplier responsibilities are written against the circuit, port, cross-connect, router, address block and monitoring system.

The third stage is automated implementation. 4Cloud's homepage specifically offers API integration, deployment pipelines and observability. The valuable deliverable is not that an engineer can make a console change quickly. It is that an approved change can be recreated, reviewed and reversed. Network prefix lists, firewall rules, identity assignments, cloud resources, monitoring thresholds and DNS records should be represented in versioned definitions wherever the underlying service permits it. Manual actions need tickets and after-the-fact capture.

The fourth stage is operation. Dashboards and runbooks, both promised on the homepage, become meaningful only when the customer can read and export them. The operating rhythm should include change review, security findings, capacity forecasts, backup evidence, recovery exercises, unallocated cost, supplier notices and expiring certificates or contracts. A compact operator can be fast because senior engineers are close to changes. The same compactness creates key-person risk unless another authorised person can follow the runbook and the customer holds the evidence.

The fifth stage is recovery and exit. Recovery is not simply restarting a virtual machine. It may require access to the identity provider, DNS, encryption keys, registry entities, upstream carrier, facility remote hands, backup catalogue and customer communications. Exit is the same dependency chain executed deliberately: reproduce service elsewhere, move traffic, verify data, rotate credentials, close supplier access and preserve audit history.

This is why the firm's control surface can be larger than its asset base. A supplier with no server ownership can still hold the privilege that deletes a subscription, changes a route, exposes a storage container or disables an alert. Conversely, a well-designed delegation can let the same supplier deliver deep operational value without owning any irreplaceable customer asset.

Identity is the production perimeter

In a multi-provider environment, the most important 4Cloud-controlled thing may be a login path. CISA's Cloud Security Technical Reference Architecture recommends least privilege across authentication realms and notes that cloud administration is exposed through provider consoles rather than protected solely by a corporate perimeter. NIST's zero-trust architecture similarly rejects implicit trust based on network location or ownership and requires authentication and authorisation before a session reaches a resource.

Those principles translate into concrete procurement tests for a small operator.

No routine work should use the customer's recovery-owner account. Each human operator needs a named identity tied to the customer's identity provider where practical, protected by phishing-resistant multifactor authentication and device policy. Shared administrator accounts destroy attribution. Long-lived access keys turn a former contractor, copied laptop or forgotten script into an open door. Routine privilege should be narrow; elevated privilege should require a reason, an approval and an expiry.

Machines need the same discipline. Deployment jobs, monitoring connectors and backup software should each receive a service identity limited to their task. Secrets should live in a managed vault, not source code, shell history, chat or a personal password manager. The customer should be able to enumerate every non-human credential, its owner, purpose, last use and rotation date. A pipeline that can create a firewall should not automatically be able to alter billing ownership or delete audit logs.

Emergency access needs separation from daily access. The customer should hold at least two tested recovery methods, stored so that a failure of the normal identity provider does not lock everyone out. Use of emergency credentials should generate an alert to people outside the operating chain. A recovery exercise should prove that the customer can regain control without Patryk Pazdro's personal device, mailbox or availability.

The responsibility split published by major platforms reinforces the point. Microsoft states that customers retain responsibility for data, identities, configuration and access across cloud service types. AWS describes the provider as securing underlying facilities and infrastructure while customers configure their workloads, permissions and data protection. Google's “shared fate” guidance adds that security is an ongoing partnership rather than a boundary a buyer can forget after signing. These are provider-wide principles, not evidence that 4Cloud currently administers any of the three platforms.

For 4Cloud, the practical question is not “Do you support multi-cloud?” The public evidence does not name those providers. The better question is “Show us exactly how your operator reaches each control plane, how access is approved, how every action is logged, and how we revoke you without breaking production.” A credible answer can be demonstrated in a sandbox: invite an operator, grant a limited role, make a change, capture the audit entry, expire the role, attempt the same action again and show that it fails.

The same test applies to AS213539. Who can update the RIPE entities? Who controls the maintainer authentication? Who creates or withdraws route-origin authorisations? Who approves upstream filters? When the 93.88.202.0/24 origin changed, a sequence of administrative and technical permissions had to line up. A customer whose service depends on a similar sequence needs those authorities named in the runbook.

Automation is evidence only when somebody else can run it

4Cloud's software-and-automation claim is the hinge between consultancy and durable operations. Automation can reduce error and accelerate recovery, but it can also encode one supplier's assumptions so densely that the customer becomes dependent on that supplier to interpret its own estate.

The minimum useful unit is a reproducible change. A proposed network, cloud or server change should start with a written intent and affected services. The implementation should be represented in reviewable configuration or, when an API cannot express it, in a precise procedure. A second authorised person reviews it. Automated checks validate syntax, policy and expected impact. The change runs through an identity dedicated to deployment, writes an audit trail and has a tested rollback condition.

The source repository belongs in the customer's organisation. 4Cloud can administer it, but should not be the only party able to grant access or recover it. Build definitions, reusable modules, dependency versions and environment variables need documentation. State files that map definitions to live resources are particularly sensitive: they may contain resource identifiers or secrets and can be as operationally powerful as administrator access. They need encryption, controlled locking, backup and a recovery procedure.

Module provenance matters. A fast-moving operator may combine open-source components, commercial monitoring, cloud-native services and its own scripts. The customer needs an inventory showing licence, source, maintained version and replacement path. A public repository does not guarantee maintainability; a proprietary script is not automatically undesirable. The test is whether the customer can rebuild the service with the documentation and rights it has purchased.

Change drift is the quiet enemy. Console edits, emergency fixes and supplier defaults can make live service diverge from the documented definition. 4Cloud should run scheduled comparisons, label unavoidable exceptions and turn every emergency action into a reviewed permanent change. “The pipeline passed” is not enough if somebody later altered a security group, route filter or backup policy by hand.

Rollback must also be defined at the service level. Reverting a file does not reverse a database migration, restore deleted data, return an address block or undo a changed external contract. A routing rollback may require the old upstream to accept the prefix and the relevant authorisation still to exist. A cloud rollback may restore infrastructure while leaving identity assignments or DNS inconsistent. The runbook needs preconditions, decision authority and verification, not merely a command.

NIST's Cybersecurity Framework 2.0 is useful here because it frames security as outcomes spanning governance, identification, protection, detection, response and recovery. It does not certify 4Cloud or prescribe a product. A buyer can use its outcomes to ask whether automation produces evidence in all six areas. The homepage speaks strongly about operation and observability; public material is much thinner on governance, recovery testing and supplier-chain assurance.

For route automation, public standards add another check. RIPE explains that RPKI origin validation lets an address holder publish cryptographically verifiable authorisation for a specific autonomous system to originate a prefix. MANRS sets out baseline actions for network operators around filtering, anti-spoofing, coordination and globally accessible routing information. Public evidence shows that 93.88.202.0/24 was validly originated in the earlier snapshot, but it does not show 4Cloud's full filtering, anti-spoofing or operational process. A buyer should request the current routing-security evidence, not infer it from an old green indicator.

A 99.95% promise needs a denominator

The homepage's 99.95% availability figure sounds precise. Over a 30-day month, 0.05% represents about 21.6 minutes; over a 365-day year, about 4 hours and 23 minutes. Yet the number has no operational meaning until the service, measurement point, interval and exclusions are defined.

Is the measured service the BGP session, a transit port, packet delivery across the firm's network, a customer application, remote-hands response or the dashboard itself? Is availability measured from one probe in Warsaw or several external locations? Does a partial packet-loss event count? What about maintenance, a customer's configuration, a failed third-party carrier, denial-of-service traffic or an unavailable cloud API? Is the commitment monthly or annual, and is the remedy a service credit or an engineering obligation?

The one-point-of-presence claim makes the boundary more important. Concentration can be rational for a compact team: fewer sites mean fewer undocumented variations and more direct knowledge. It can also create common-cause exposure if power, cross-connects, upstream paths and operator access converge in one place. A second carrier in the same building does not necessarily provide a physically diverse route. A second cloud region does not help if identity, DNS or deployment is singular.

“Tier I” needs equally careful reading. The Uptime Institute's tier classification describes Tier I as basic capacity with dedicated cooling, uninterruptible power and generation, but without the maintainability and fault tolerance of higher levels. The 4Cloud homepage does not identify the facility or state that Uptime Institute certified it. The phrase may be the company's own description. A buyer should ask for the facility name, exact tier claim, certificate or design basis, power paths, maintenance constraints and responsibility for remote hands. It should not translate “Tier I” into “top tier.”

The correct service-level schedule would decompose the promise. Carrier and exchange components get port and packet metrics. Managed servers get power, hardware-response and operating-system boundaries. Cloud work gets platform exclusions and customer-configuration boundaries. Operations get acknowledgement and restoration targets by severity. Backups get completion and restore objectives. Each component names the evidence source, retention period, escalation path and remedy.

4Cloud promises live dashboards and utilisation exports. Those are promising instruments if the customer can independently reconcile them. A dashboard should show raw measurement provenance and survive contract termination through export. A monthly report should list excluded minutes rather than simply display a green percentage. A service credit is less valuable than a timeline, root cause, corrective action and proof that the fix was tested.

The price is hidden in the meter

No public price list appears in the company's cited homepage. That is common for bespoke infrastructure work, but it places more weight on the quotation's unit economics. The 600 Gbps claim is a capacity statement, not a price.

A network proposal can combine a port fee, committed data rate, burst usage, 95th-percentile billing, transit, peering, cross-connects, address rental, route announcements, denial-of-service protection, hardware, rack power and remote hands. A server proposal may add purchase or lease, warranty, spares, installation, software licences and replacement labour. A cloud proposal adds provider consumption, support plans, marketplace products, data transfer, logging, backup storage and the operator's engineering fee.

Advertising-technology integration may introduce volume or revenue-linked economics that should not be blended invisibly with infrastructure.

The quote should separate pass-through charges from 4Cloud's own fees. Pass-through invoices should name the upstream supplier, currency, tax treatment, discount allocation and markup. If 4Cloud aggregates a commitment and resells capacity, the customer should understand whether it receives a dedicated allocation, shared pool or best-effort burst. If the customer contracts directly with the supplier, 4Cloud's fee can be a project price, monthly retainer, incident rate or measurable managed-service unit.

Ownership of discounts matters. A small operator may secure better rates through pooled buying, but a customer can become unable to compare prices or leave without losing the commercial benefit. Committed-use discounts can save money while creating a time-based exit cost. Address rental and bundled transit can make an application dependent on an allowlisted range that cannot move. A low monthly management fee may be offset by expensive change requests or emergency support.

FinOps guidance on allocation explains why account hierarchy, tags, labels and derived metadata are needed to assign technology cost to responsible teams and products. For a 4Cloud engagement, cost metadata should be part of provisioning, not a finance clean-up months later. Every resource should have an owner, environment, service and cost centre. Shared network, monitoring and support charges need a documented allocation rule. Unallocated spend should appear as an exception.

The buyer should run four reconciliations during a pilot. First, map every provider invoice to the contract. Second, map every billed resource to the inventory. Third, map each resource to a business owner. Fourth, recompute any usage-based 4Cloud charge from exportable raw data. The exercise tests both pricing transparency and operational inventory. If the parties cannot explain a small pilot bill, scale will not make it easier.

Pricing should also put a ceiling around failure. Define included incident hours, after-hours rates, supplier escalation charges, data-restoration work and exit assistance. A pre-agreed rate for extraordinary work is better than an undefined “reasonable cost.” The goal is not to force a small supplier into a commodity tariff; it is to make the meter visible before dependence grows.

Silence about incidents is not an incident record

The public evidence reviewed contains no 4Cloud status history, security advisory, named post-incident report or regulator finding. The homepage says the firm owns documented incident response and offers around-the-clock escalation for managed clients, but publishes no example. That absence is a due-diligence gap, not proof that there have been incidents, and not proof of an incident-free history.

The routing withdrawal in February must not be mislabelled as an outage. It is a change in public reachability for AS213539 and the /24 it had originated. Without customer service data, contract context or a contemporaneous notice, it could represent an orderly end of assignment. Treating every withdrawn prefix as a failure would be technically unserious.

Public reputation evidence is also too thin for a quality verdict. A GoWork listing presents an aggregate derived from three ratings in the indexed view, but provides no verified link to a network engagement, no technical account and no basis for separating employment sentiment from customer service. It is too weak to use as evidence of reliability.

Procurement must therefore create its own incident evidence. Ask for a redacted example timeline showing detection, severity, acknowledgement, customer update, containment, recovery and review. Ask who holds the incident commander role when the sole trader is unavailable. Ask which suppliers have their own escalation clocks and whether 4Cloud may communicate directly with them. Ask how evidence is preserved when logs sit in a customer's account.

Then run a tabletop exercise. Choose a failure that crosses boundaries: an operator credential is suspected compromised while a route change and a cloud deployment are in progress. The team must disable access without destroying evidence, stop unsafe automation, determine which resources changed, keep customer communications moving, validate routing authorisations and restore from a known state. A second exercise should assume the normal identity provider is down. A third should assume the Warsaw location cannot be reached.

Recovery evidence should be mechanical. Pick a service, restore it into an isolated environment, compare data, change DNS or routing in a controlled window, and record the time to useful service. Confirm that the customer—not only 4Cloud—can retrieve backups and audit logs. Verify that alert delivery reaches two customer-controlled destinations. An incident promise becomes credible when these tests produce timestamps and corrective actions.

Support quality is equally testable. During a paid pilot, submit a routine request, a security-sensitive change and an urgent scenario. Measure acknowledgement, technical accuracy, handoff, documentation and closure. Direct access to senior engineers can outperform a large service desk, but only if coverage, substitution and escalation are explicit. The commercial virtue of a compact team should not require the customer to accept a single point of human failure.

Compliance follows the data, not the word “cloud”

The public homepage uses “compliance-ready documentation” but names no certification, audit report, privacy terms or control framework. No public evidence reviewed here establishes an ISO certificate, SOC report or sector authorisation for the trader. That is not evidence of non-compliance; small suppliers often provide contractual documents privately or operate within a customer's certified environment. It means a buyer must request proof appropriate to the actual service.

The first question is whether 4Cloud processes personal data for the customer. Administrative logs can contain names, email addresses, device details and network identifiers. Support tickets may include customer data. Backups and observability can expose application content. If 4Cloud acts as a processor, Article 28 of the GDPR requires sufficient guarantees and a binding contract defining the processing, security obligations, sub-processors, assistance, audit and return or deletion. A vague infrastructure statement does not replace that data-processing schedule.

The supplier map must extend beyond 4Cloud. A facility, remote-hands contractor, transit carrier, monitoring service, ticketing system, backup platform and public-cloud provider may each receive data or operational access. The customer needs locations, purpose, access type, retention and change notification. If 4Cloud merely configures a provider in the customer's account, the legal role may differ from a bundled service in which 4Cloud chooses and contracts the provider. The architecture and contract should tell the same story.

For organisations within scope, NIS2 raises the importance of the same evidence. Article 21's measures include incident handling, continuity, supply-chain security, secure acquisition and maintenance, effectiveness testing, cryptography, access control, asset management and multifactor authentication. Whether a particular customer or service falls within national implementing law requires legal analysis; the list is still a useful supplier questionnaire because it follows the real operating chain.

Financial entities have a more detailed procurement reference in DORA. Articles 28 to 30 call for due diligence on ICT suppliers, concentration and substitutability analysis, written allocation of rights, service levels, processing locations, data access and return, incident assistance, audit cooperation and termination rights. DORA does not make 4Cloud a critical provider, nor is it relevant to every buyer. It illustrates the contract detail that becomes necessary when a small operator supports an important function.

Evidence should be proportionate. A small non-critical pilot may need an architecture diagram, access-control export, backup test, supplier list and insurance proof. A regulated production service may need control descriptions, vulnerability handling, penetration-test scope, personnel screening, data-processing terms, audit rights, continuity tests and financial-resilience information. Demanding an expensive badge without checking the service boundary can be theatre; accepting a badge without testing access and recovery is worse.

The company can turn its compactness into an advantage by maintaining a concise, current assurance pack: legal identity, service map, sub-suppliers, data locations, privileged-access process, secure-development practice, vulnerability intake, incident procedure, continuity test, insurance, sample report and exit plan. The public evidence does not show such a pack. Procurement should make its delivery an early milestone.

Lock-in lives in permissions, history and exceptions

Customers often look for lock-in in proprietary software. In a managed infrastructure relationship, the harder lock-in can sit in less visible places: who owns the account, who understands the route filter, where deployment state is kept, which manual exception prevents a rebuild, how a discount is committed, and which email address can reset the administrator.

The European Data Act makes switching a current contractual issue for data-processing services. Regulation (EU) 2023/2854 requires contractual support for switching and sets a schedule under which reduced switching charges may apply until 12 January 2027, after which providers may not impose switching charges for the switching process. Its exact application depends on the service and facts. It does not make migration costless: customers can still face architecture work, standard service fees, third-party charges and operational risk.

For 4Cloud, an executable exit should cover at least eight bundles.

The identity bundle lists every human and service identity, role, group, emergency method and recovery contact. Exit removes 4Cloud access, rotates secrets it could have seen and proves that scheduled jobs still run.

The configuration bundle contains repositories, dependency versions, environment definitions, state, manual procedures, diagrams and decision records. A replacement engineer should be able to produce a plan without contacting the incumbent.

The data bundle defines export format, encryption, integrity checks, retention and deletion. Backups are restored before the source is destroyed. Observability data and incident history are exported because losing them can blind the new operator.

The network bundle covers domains, DNS zones, certificates, addresses, autonomous-system relationships, route objects, route-origin authorisations, reverse DNS, firewall rules, tunnels, allowlists and carrier contacts. The journey of 93.88.202.0/24 shows why address rights and origin changes must be explicit. A prefix that can return to a supplier cannot be the undocumented permanent identity of an application.

The commercial bundle lists direct and reseller contracts, commitments, renewal dates, credits, deposits, equipment ownership and termination charges. It says which discounts survive a transfer and which do not.

The physical bundle inventories hardware, serial numbers, rack units, spares, media, access lists and removal procedure. “Remote hands” must include who may authorise a person to touch a device after the relationship ends.

The knowledge bundle includes runbooks, known defects, accepted risks, recurring maintenance and vendor cases. Recorded knowledge transfer is followed by a customer-led operation while 4Cloud observes.

The acceptance bundle defines parallel running, performance checks, data reconciliation, security validation and final sign-off. Access is not removed merely because files were delivered; it is removed after the replacement path works and the customer has accepted the result.

These bundles should exist from the beginning. Waiting until termination guarantees that undocumented exceptions are discovered under time pressure. A quarterly exit rehearsal can be small: rebuild one non-production service from the customer repository, restore data, transfer on-call to another engineer for a day and verify that 4Cloud's routine privilege can be removed and restored through approval.

Lock-in is not always undesirable. Deep operational knowledge and reusable automation can make staying with a good supplier economically rational. The harmful version is unmeasured dependence: the customer cannot estimate switching effort, identify the dependencies or exercise a contractual right without asking the incumbent to explain it. 4Cloud can distinguish itself by making its own replaceability a deliverable.

Competition is a choice about where to place responsibility

4Cloud Systems does not compete only with other small Polish infrastructure consultancies. It competes with several ways of dividing control.

A customer can contract directly with cloud providers and carriers, then operate everything with its own staff. That maximises contractual visibility and can reduce reseller dependence, but requires enough engineering coverage to design, secure and recover the estate.

It can hire a large managed-service provider. That may bring broader coverage, formal assurance and a staffed service desk, while adding process layers, standardised tooling and higher minimum commitments. Scale does not automatically produce better architecture or faster senior attention.

It can split the work among a network operator, colocation provider, cloud specialist, software integrator and advertising-technology adviser. Specialists may be deeper in each layer, but the customer becomes the integrator and must prevent gaps between contracts.

It can use 4Cloud as the accountable operator while keeping every underlying account and contract direct. That arrangement best fits the control-surface thesis: one senior technical party coordinates changes without becoming the owner of irreplaceable assets. It depends on disciplined delegation, documentation and coverage.

Or it can buy a bundled 4Cloud service in which upstream suppliers are largely invisible. One invoice and one escalation path can be valuable to a small customer. The trade-off is concentration, price opacity and a more complex exit. The bundle should therefore identify every material dependency and preserve customer data and configuration rights.

The homepage's combination of routing, servers, CDN, automation and programmatic advertising could be distinctive for media workloads. Public evidence does not provide named customers, benchmarks or case studies proving that integration. A buyer with that need should commission a narrow trial in which network delivery, observability and advertising-system change are measured together. The result, not the breadth of the capability list, should decide whether integration is an advantage.

A procurement test built around the missing boundaries

The commercial question is not whether 4Cloud Systems is real. The identity and routing evidence answer that. The question is whether its real control surface is documented well enough for a customer to entrust production to it.

Start with a proof pack before requesting a grand architecture.

Ask for the current legal extract and VAT details, proof that the contracting party controls 4cloud.systems, and confirmation that invoices use the same entity. Ask for the RIPE membership and AS213539 responsibility, including maintainer roles and the reason the autonomous system currently originates no visible prefixes. The answer may be entirely benign; the quality of the explanation and evidence is itself useful.

Ask the company to define WAW-1. The response should name the facility, contracted party, rack or service boundary, power and network paths, remote-hands arrangement and exact basis for “Tier I.” Ask for a diagram showing which components 4Cloud owns, leases, resells, manages for customers or accesses through partners. Ask how the 600 Gbps figure is calculated and for a redacted utilisation export that uses the same definition.

Ask for a service catalogue that turns broad capabilities into deliverables. Network architecture should specify routing policy, filtering, address responsibility, monitoring and change control. Colocation should specify hardware, power, access, spares and remote hands. CDN work should specify cache ownership, purge authority, logs and origin protection. Automation should specify repository, state, approvals, test and rollback. Advertising integration should specify data flows, platform accounts, consent responsibilities and commercial separation.

Ask for an identity demonstration. The customer creates a sandbox under its own organisation. 4Cloud joins through named federated access, receives a narrow role, deploys a harmless resource, produces the audit entry and loses access automatically at the agreed time. The customer invokes emergency recovery and confirms that no personal 4Cloud mailbox or device is required.

Ask for a routing demonstration appropriate to the proposed service. Review an intended prefix and origin, the registry entity, authorisation, upstream filter, monitoring and withdrawal plan. If the customer will not use 4Cloud's AS, trace the equivalent change path through the customer's or carrier's number. Require a four-eyes review for route-policy changes and an alert from an external observer.

Ask for a billing demonstration. Provision a small tagged workload or measured network service. Reconcile the provider invoice, 4Cloud fee, usage export, markup, tax and cost allocation. Change a resource and confirm that both inventory and budget alert update. Delete it and confirm the charge stops according to the provider's billing rules.

Ask for a failure demonstration. Break a non-production dependency, invoke the support path, restore from a known backup and write the timeline. The exercise should cross a supplier boundary so that 4Cloud has to use its escalation map rather than fix everything alone. Record the difference between acknowledgement, workaround, restoration and permanent correction.

Ask for an exit demonstration before the main contract. Export configuration and logs, transfer operation to a customer engineer, revoke 4Cloud access and rebuild one component. Price the assistance in advance. A supplier confident in its operating discipline should be able to make this routine.

Use a staged commercial commitment. A paid discovery phase produces the dependency map, responsibility matrix, risk register, implementation plan and fixed proof criteria. A sandbox phase tests identity, automation, billing, support and exit. A limited production phase adds one non-critical service with clear recovery objectives. Expansion follows only when evidence closes the gaps.

The contract should attach the resulting artefacts. It names the legal entity and every material sub-supplier; identifies service and data locations; allocates account, equipment, address and software ownership; defines availability and support measurements; covers security, incident notice, audit and vulnerability handling; provides data return, configuration rights and deletion; sets change and subcontractor notice; prices extraordinary work; and preserves termination assistance.

Governance should be light but real. A monthly operational review covers service levels, changes, incidents, vulnerabilities, restores, capacity, costs, supplier changes and expiring items. A quarterly control review samples privileged access, runs a restore and rehearses one exit component. An annual review redraws the architecture from actual evidence rather than copying last year's diagram.

The decision should be evidence-weighted. Strong results would be a coherent asset boundary, customer-owned accounts, precise delegation, reproducible change, external monitoring, reconcilable bills, tested recovery, substitute coverage and an exit that works. Weak results would be administrator access through personal identities, bundled charges without raw data, undocumented manual configuration, reliance on one person's availability, unverified facility and capacity claims, or refusal to test revocation and handover.

This process is not designed to disqualify a small provider. It lets a small provider prove the advantages that size can offer: short feedback loops, senior attention and low organisational distance. It also addresses the risks that size cannot wish away.

What to watch after signing

The first watchpoint is the return of routing activity. RIPE currently sees AS213539 originate nothing. A new prefix, upstream or exchange presence would be material evidence of renewed network operation. It should be checked against registry authorisation, observed routes and the service actually sold. A directory field alone is limited public evidence.

The second is reconciliation of the public claims. The firm could strengthen its position by publishing the definition of managed capacity, the facility basis for WAW-1, a bounded service-level description, a security contact and a status history. Publication is not a substitute for customer evidence, but it reduces ambiguity.

The third is supplier concentration. Track whether supposedly diverse links share one building, carrier, address lessor, DNS host, identity provider or operator. The public website's dependence on separate shared hosting is not itself a customer risk, but it is a reminder that brand, control plane and production can sit on different suppliers.

The fourth is privilege accumulation. Every project tends to add roles, service identities, tunnels, repository access and emergency exceptions. Review them against actual use and remove what is no longer necessary. A quarterly access export should become smaller when projects end.

The fifth is automation drift. Monitor failed deployment checks, manual changes, unpinned dependencies, stale modules, unreconciled state and runbooks that no longer match provider consoles. Recovery confidence decays unless somebody rebuilds from the documented source.

The sixth is financial drift. Compare committed capacity with usage, allocate shared charges, inspect support and egress, and flag resources with no owner. A transparent operator should help the customer reduce waste even when doing so reduces pass-through spend.

The seventh is recoverability without the proprietor. The legal form is a sole proprietorship, but that does not reveal team size. The homepage speaks of a senior team. Procurement should verify the named substitute, access path and customer communication plan rather than infer either a one-person or many-person operation.

The eighth is exit cost. Update the dependency inventory, transfer-time estimate and replacement test as the estate changes. The cheapest point to preserve portability is before a new exception enters production.

The verdict: real control, still to be bounded

The public record supports a qualified conclusion. Patryk Pazdro trading as 4Cloud Systems is a provable Polish business linked by tax number, address, domain and RIPE records. It has done actual network work: AS213539 originated a globally observed /24 for months. Its present route table is empty, and the former prefix now sits with another network. That is not a reason to dismiss the firm. It is the clearest illustration of the service being sold.

4Cloud's durable product is unlikely to be the physical substrate alone. It is the authority to configure systems spanning customer assets and third-party platforms: identities, routes, automation, monitoring, bills, recovery and change. Used well, that authority gives a small customer senior operational capability without forcing it to build a full team. Used carelessly, it creates dependence on credentials, undocumented choices and one relationship.

The homepage asks operators to prefer facts over slides. Buyers should accept the invitation literally. Ask for the route history, facility boundary, capacity calculation, account map, privilege log, raw bill, restore result and exit rehearsal. Keep ownership where ownership creates leverage. Delegate only the access needed to operate. Make every important change reproducible and every emergency recoverable by somebody else.

The /24 that left is not a scandal and not a footnote. It is a compact lesson in cloud and network procurement: infrastructure can be rented, routes can move and suppliers can change, but control must always have an owner, a record and a tested way home.