Storm Iraq and the 333-Path Test: Where an Operator’s Control

Summary

Storm can be tied to the exact Iraqi legal entity through RIPE NCC membership, organisation and routing records, while the stormnetwork.net domain and contact details provide a further operating bridge.
At the evidence cut-off, AS212280 originated nine visible IPv4 /24s. A RIPE RIS test of one representative prefix found 333 paths, all entering Storm through AS203214 and AS208293; the same immediate pair appeared in equivalent checks of the other eight prefixes.
That is meaningful operator evidence: Storm controls route origination and has valid RPKI authorisation for the nine routes. It is not proof of diverse international capacity, a protected last mile, a certified data centre or a tested restoration process.
A buyer should make Storm demonstrate physical route diversity, upstream independence, power autonomy, support escalation, regulatory status and failover under load before treating a second circuit or a second Storm ASN as genuine resilience.

The packet that tells the commercial story

An internet contract usually begins with a bandwidth number. A serious continuity assessment should begin with the last four autonomous systems in a route.

At 15:59:50 UTC on July 18, 2026, the RIPEstat BGP State result for 185.122.252.0/24 contained 333 paths observed through RIPE Routing Information Service collectors. In every one, AS203214 appeared immediately before Storm’s AS212280. In every one, AS208293 appeared immediately before AS203214. In 332, AS60051 appeared immediately before AS208293. The other path contained a private-use ASN at that position, a reminder that collector data can contain quirks and should not be read as a contractual circuit diagram.

The important finding is simpler. For that prefix, a geographically distributed view of the global table showed one immediate way into Storm. Equivalent freeze-time checks across the other eight /24s showed the same immediate AS203214–AS212280 edge and the same AS208293 step before it. Public BGP observation cannot reveal fibre strands, contractual capacity, protected ducts or the difference between a paid transit circuit and another commercial arrangement. It can reveal concentration. Here it does.

This is the useful opening mechanism for understanding Storm for Information Technology, Internet Services, Communications, Electronic Solutions, Software, and Automation LLC. The company is unusually hard to assess from its public commercial surface. Its website presents software development, mobile applications, web design, cybersecurity and automation offerings, plus a Baghdad contact point, but it does not publish internet packages, an access footprint, service-level terms, a status page or a network map. Its LinkedIn company page makes a much broader set of self-reported claims: business internet, FTTH, wireless networks, BGP routing, traffic engineering, data-centre services, cloud and hosting, and tens of thousands of users across multiple Iraqi locations. Those claims describe the sort of operator Storm wants the market to see. The routing table shows the narrower set of things outsiders can independently test.

That distinction matters because an ISP’s practical product is not “the internet”. It is a chain of controlled and contracted components. A customer’s traffic begins at a router or optical terminal, traverses a building entry and an access link, reaches an aggregation site, crosses a core, leaves through one or more upstream networks, and then depends on distant transit, peering and content delivery. When performance deteriorates, a second chain starts: monitoring, fault isolation, field dispatch, upstream escalation, customer communication and restoration. An operator can own some links, lease others and resell still others.

The commercial name on the invoice says little about where its control ends.

Storm’s number-resource record establishes a real routing control surface. It does not, by itself, establish a resilient service. The most defensible reading is therefore neither “mere reseller” nor “fully independent carrier”. Storm has stronger evidence of operational agency than a retailer that simply hands customers another network’s addresses. Yet its currently visible route is nested inside a larger Iraqi chain, and its public disclosures do not let a buyer determine whether alternative capacity exists but is idle, invisible to collectors, or absent.

The procurement question is not whether Storm is legitimate enough to call an operator. It is whether the precise service being purchased gives Storm enough physical, routing and organisational control to meet the buyer’s recovery objective. The 333-path test turns that abstract question into a concrete due-diligence programme.

Proving the exact Storm, without importing a namesake

The identity boundary is unusually important here. “Storm” is a common telecom and technology name, and public network directories contain similarly named businesses. The correct entity is the Iraqi company with the full legal name used in this article, not a foreign security provider, a different Iraqi network, a product brand or an unrelated “Storm” service.

The strongest bridge is the RIPE NCC member page. It records the exact legal name, an address in Baghdad, Iraq as the service area, a telephone number and an email address at stormnetwork.net. The current RIPE organisation record for ORG-SFIT5-RIPE repeats the exact name, identifies Iraq as the country, records company registration number 13254, classifies the organisation as a local internet registry, supplies the same Baghdad address and phone number, and names a dedicated abuse-contact handle.

The operating-domain bridge is not based on a loose similarity. RIPE’s membership contact uses the company domain. Storm’s own site uses a phone number ending in 8290 and an [email protected] address; RIPE’s administrative role also uses the 8290 number, while the membership record uses a closely related 8294 number. The site locates the business in Baghdad’s Karada/Al-Sinaa area, consistent with the public company page’s Baghdad, Karada Al-Sinaa location and the RIPE address in Quarter 906, Street 16. Taken together, exact name, registration number, domain, locality and contact overlap establish a much stronger identity bridge than a logo or a search result could.

There is still a timeline wrinkle. The LinkedIn page self-reports that Storm was founded in 2022 and lists a workforce band of 51–200. Those are platform-supplied company assertions, not audited employment or incorporation evidence. RIPE routing records bearing the Storm name go back much further: AS203811 was created in October 2015, and AS203459 in January 2016. That difference need not mean either source is false. The page may use the start of a newer commercial brand or corporate phase, while number resources may have been transferred or maintained through organisational continuity.

It does mean a buyer should request the current company registration, any predecessor or transfer documentation relevant to the contracted service, and proof that the signatory controls the network resources being sold.

This is also why the ASN should never be treated as a substitute for counterparty checks. RIPE accurately records resource administration; it does not certify balance-sheet strength, licence scope, staff levels, beneficial ownership, field coverage or the enforceability of a customer contract. Conversely, a polished company page cannot prove route control. Identity becomes dependable only when legal, operational and commercial evidence agree.

For Storm, they agree at the core: the exact legal entity, current RIPE organisation, stormnetwork.net domain and AS212280 are connected by primary records. They become less complete at the edges. Public material does not explain why the current RIPE organisation entry was created in November 2025 while some attached ASNs are a decade old. It does not publish a corporate history that reconciles the 2015–16 network record with the 2022 founding claim. It does not explain whether “Soft Storm”, the branding on the current site, is a division, a refreshed trading style or simply the same business presenting a software portfolio. None of those gaps invalidates the network identity. Each belongs in a contracting checklist so that similarly named entities, historical registrations and operating brands cannot be silently substituted.

Five registered ASNs, one dominant live edge

Storm’s current RIPE organisation is associated with more than AS212280. An inverse RIPE Database search on ORG-SFIT5-RIPE returns five autonomous-system numbers: AS203459, AS203811, AS211235, AS212280 and AS212392. It also returns four IPv4 allocations—185.122.252.0/22, 185.133.224.0/22, 185.217.61.0/24 and 45.89.20.0/24—and the IPv6 allocation 2a06:7fc0::/29.

Five ASNs sound like redundancy. The live routing picture is narrower.

The RIPEstat announced-prefix result for AS212280 showed nine globally visible IPv4 /24s during the frozen interval: 45.89.20.0/24; all four /24s from 185.122.252.0/22; three /24s from 185.133.224.0/22; and 185.217.61.0/24. It showed no IPv6 route. AS203811 originated one /24, 185.239.179.0/24, but the corresponding RIPE records identify that address space and route maintenance with Max Link rather than a Storm allocation. That route may reflect transit, alternate origination or another operational arrangement; it should not be counted as Storm-owned address capacity.

The nine AS212280 prefixes total 2,304 IPv4 addresses. That is a material routable footprint for a regional operator, but raw address count does not reveal subscriber count, paid capacity or geographic coverage. A /24 can serve residential customers behind address translation, business customers with public addresses, infrastructure, hosting or some mixture. It can be fully utilised or nearly empty. What the set does show is that Storm is originating multiple address blocks under its own routing policy rather than presenting only addresses originated by a wholesaler.

The history is more informative than the snapshot. RIPE RIS routing history for AS203459 shows 185.133.224.0/24, 185.133.225.0/24 and 185.133.226.0/24 visible from that Storm ASN from January 2016 until April 12, 2026. The four 185.122.252.0/24–185.122.255.0/24 routes were visible from AS203459 from November 2017, also ending in April 2026 at normal visibility thresholds. The AS212280 history begins with 185.217.61.0/24 in late 2020 and shows the rest of the present set moving or consolidating there during 2025 and 2026.

That looks like a routing reorganisation, not the appearance of a network from nothing. It proves sustained operational history at the ASN and prefix layer, while also creating questions. Was traffic moved between Storm-controlled routers in separate sites? Was a legacy edge retired? Did upstream contracts change? Were customers renumbered, or did the prefixes move transparently? Did any service interruption accompany the transition? The public routing history cannot answer. A business considering Storm should ask for a short change narrative and post-change topology, especially because the reorganisation is recent.

The additional ASNs require similar discipline. An ASN can be held for a future site, reserved for a distinct routing policy, retained after a migration or simply unused. The current authoritative RIPE entries do not disclose facility addresses or physical attributes. An ASN label is not a rack, a generator, a cross-connect or a disaster-recovery site. Two Storm circuits delivered from “different ASNs” would not be diverse if they share the same access duct, aggregation router, power system and upstream path.

IPv6 presents the inverse situation: the organisation has an allocation but no visible route from its dominant edge at the cut-off. Iraq’s Internet Society country report records effectively zero measured IPv6 adoption nationally, so Storm is not alone. Nevertheless, an enterprise procurement should ask whether native dual stack is available, whether the allocation is routed elsewhere, whether customer IPv6 is planned and whether security and monitoring cover it. Holding address space is not deployment.

Route authorisation is real progress, not an SLA

Every one of the nine current AS212280 routes returned a “valid” result when its prefix and origin were checked through RIPEstat’s RPKI validation service at the evidence cut-off. The bgp.tools view of AS212280 independently marked the nine visible /24s as covered by valid route-origin authorisations.

This is a meaningful strength. A valid result means that a cryptographically verifiable statement authorises AS212280 to originate the relevant prefix within the permitted length. It reduces the risk that an accidental or malicious announcement from a different origin will be accepted by networks that enforce route-origin validation. It also demonstrates that somebody responsible for Storm’s number resources has done a piece of operational hygiene that many small networks still neglect.

It does not certify the whole path. RIPE NCC’s explanation of BGP origin validation is explicit that current RPKI functionality validates the origin, not every AS in the route. A valid Storm ROA says AS212280 may originate 185.122.252.0/24. It does not say AS203214 is the best or only legitimate neighbour, that the upstreams filter customer announcements correctly, that traffic cannot be diverted after the origin, or that the circuit has capacity during a fault.

Nor does RPKI prove that inbound and outbound paths are symmetric. BGP chooses routes according to policies distributed across many networks. A customer can observe one inbound chain from RIPE collectors while Storm sends traffic out another way. That is why the 333 paths are evidence of globally observed reachability and concentration, not a complete traffic-flow map. A useful procurement test needs measurements in both directions, from multiple target networks, during normal operation and controlled failover.

A changing network also creates a hygiene question: are route objects, ROAs, prefix filters and customer authorisations aligned with the post-migration design? A stale route object is not itself an outage. A clean, current set makes mistakes easier to prevent and incidents easier to diagnose.

The stronger benchmark is operational behaviour. The MANRS actions for network operators call for correct filtering, source-address validation, globally accessible coordination contacts and publication of routing information. Storm has evidence for part of that picture: authorised origins and RIPE contact data. The public record does not demonstrate customer prefix filtering, anti-spoofing, route-leak controls, maximum-prefix limits, routing incident drills or participation in MANRS. A buyer should not demand a badge for its own sake. It should turn those practices into questions that an engineer can answer and a contract can support.

Ask Storm for the exact ASNs and prefixes used by the proposed service; the upstream ASNs under normal and failover conditions; the maximum-prefix and route-filter policy; the handling of customer-owned address space; the time required to create or change a route-origin authorisation; and the escalation path for a hijack or leak. Then compare the answer with live observations. That is how valid RPKI becomes one element of a reliability case instead of decorative security language.

The visible dependency chain

RIPEstat’s neighbour view for AS212280 observed AS203214 on the left of Storm in AS paths and AS212392 on the right. RIPE’s endpoint documentation cautions that “left” and “right” describe position in observed paths. They are not contractual labels. Even so, the prefix-level paths make AS203214’s role hard to ignore: all 333 routes to the sampled /24 reached AS212280 through it, and the same immediate neighbour appeared for all nine current prefixes.

AS203214 belongs to Hulum Almustakbal Company. Its public bgp.tools page describes a much larger Iraqi eyeball network and lists AS208293, AlSalam State Company, and AS60051, Earthlink Telecommunications Equipment Trading & Services, as upstreams. The observed path to Storm commonly ran AS60051–AS208293–AS203214–AS212280. In practical terms, a Storm customer’s international reach was publicly visible through a hierarchy of other Iraqi networks at the cut-off.

That does not make Storm a simple reseller. AS212280 originates Storm-authorised prefixes and has downstream visibility of its own. A reseller whose control ended at a wholesaler’s customer portal might never appear in BGP. Storm can set origin policy, move its prefixes between its own ASNs, maintain route authorisations and operate routers that exchange routes with other networks. Those are genuine control points.

The chain does show where independent proof becomes necessary. If the proposed service uses the same physical hand-off and the same AS203214 route as Storm’s general access network, then an outage or congestion at that boundary can affect all nine origin prefixes. A second customer circuit on a different Storm /24 would not remove that shared dependency. A second Storm ASN routed through the same neighbour would not remove it either. Real diversity requires a failure boundary that is different in fact, not merely a different address or invoice line.

Storm’s RIPE routing-policy entries list many potential import and export counterparties. Such declarations can be broad, historical or prepared for relationships that are not currently visible. At the cut-off, the observed table was far sparser. That gap between declared possibility and observed use is not evidence of wrongdoing; it is a reason to request a current topology signed off by the network team. The buyer should ask which counterparties carry production traffic today, which are physically independent, which are hot, which are cold, what capacity each has, and how routes change when one is withdrawn.

An operator can also have private interconnection that public collectors do not see. A cache, content-delivery node or local peer may serve traffic without appearing as an upstream in the global table. Likewise, a backup transit circuit may remain dormant until failure. The right conclusion is therefore not “Storm has only one circuit”. It is “public evidence demonstrates one active route into the observed prefixes and does not demonstrate an independent alternative”. Storm can close that evidence gap with circuit identifiers, letters from carriers, protected-route diagrams, failover captures and customer-visible tests.

Capacity is a separate unknown. A BGP path carries no committed-information rate. The same path can sit on a lightly used 100 Gbps link or an oversubscribed 1 Gbps hand-off. It can have spare capacity at noon and saturate during evening demand. For an SME, median speed during a sales demonstration matters less than the lowest usable performance during peak load or an upstream failure. A credible proposal should identify committed bandwidth, burst treatment, contention, international versus local capacity, packet-loss and latency targets, and the measurement point at which each applies.

The 333-path result is thus best treated as a map of bargaining power. Storm controls the final routing step. Hulum and the networks before it control important earlier steps. The customer needs to know which party has the tools, contractual authority and staff to act at each boundary. If Storm can open an upstream ticket but cannot reroute traffic, its support promise should say so. If it can reroute, the failover should be demonstrated.

The missing physical map

The internet ultimately runs through places. Cables enter buildings. Routers occupy racks. Cross-connects terminate in meet-me rooms. Batteries bridge generator starts. Cooling systems fail in heat. Public routing data can identify administrative edges, but it cannot locate these physical dependencies.

Storm’s commercial page claims modern data-centre systems, FTTH infrastructure, wireless networks and service across multiple sites in Baghdad and other provinces. The company website gives a Baghdad office location and lists technology services. Neither source publishes the address of an operating facility, the ownership of fibre, the number of points of presence, a route map, a facility certification, power design, carrier list or cross-connect inventory. The claims may be accurate; the evidence needed to test them is not public.

PeeringDB sharpens the gap. Storm’s network record correctly links the exact company name, AS212280 and stormnetwork.net, classifies it as a cable/DSL/ISP network and states an open peering policy. Yet the network-to-facility result was empty, the network-to-exchange result was empty, and the public point-of-contact result was empty at the freeze.

Absence from those fields is not proof that Storm has no facilities or peering. PeeringDB describes itself as community-maintained, says only about a third of autonomous systems use it to share interconnection information, and defines netfac and netixlan as records of a network’s facility and exchange presence. An operator may be absent because it has not maintained the record, because interconnection is private, or because its upstream provides the physical presence. For a buyer, all three possibilities deserve different commercial treatment.

The local opportunity is real. Internet Society’s IRAQ-IXP tracker reported 30 member ASNs and 1,173 Gbps of cumulative port capacity in May 2026, with content networks and a route server among the membership. Storm’s AS212280 record did not disclose a PeeringDB exchange connection. That does not establish whether Storm reaches the exchange indirectly, privately or not at all. It does mean a buyer cannot infer local peering merely because an Iraqi exchange exists or because an internet-routing set includes Storm’s ASN.

Physical proof should be proportionate to the service. A small shop buying best-effort access may only need a serviceability check and clear repair contact. A bank branch, clinic, logistics depot or cloud-dependent office needs more:

the exact building entry and last-mile medium;
whether that medium and the civil route are owned, leased or supplied by another operator;
the aggregation and core sites that the circuit traverses;
the power design and tested runtime at each site;
whether primary and backup links share poles, ducts, towers, rooms, optical distribution frames or upstream routers;
the facilities where Storm meets AS203214 and any alternative provider;
the restoration owner and spare-parts location for every segment.

A site tour is not always possible, but the operator can still provide redacted diagrams, photographs with dates, equipment inventories, carrier letters, power-test records and maintenance procedures. The goal is not to expose sensitive security details. It is to establish that “DC1”, “DC2”, “backup route” and “independent fibre” correspond to different failure domains.

Reconstructing the service a buyer would actually receive

Storm does not publish enough product detail to describe a standard customer journey as fact. A buyer can, however, map the control questions that any credible Storm proposal must answer.

The first stage is serviceability. The company’s self-description spans FTTH, wireless and business internet, which implies that access technology may vary by location. A salesperson should therefore identify the precise medium, not merely say “fibre” or “wireless”. Fibre can be passive optical access shared across many customers, an Ethernet hand-off over an upstream network, or a dedicated strand. Wireless can mean a licensed microwave link, an unlicensed point-to-point radio or a shared point-to-multipoint sector. Each has different capacity, interference, repair and power characteristics.

The second stage is installation. The proposal should name the customer-premises equipment, demarcation point, optical or radio path, public-address allocation, routing mode and responsibility for configuration. If Storm supplies a managed router, the customer needs access and change rules. If the customer supplies it, Storm needs supported interface and routing specifications. For a dual-link design, both parties must agree how health is detected and how traffic moves: manual change, tracked static route, dynamic routing, software-defined policy or application-level failover.

The third stage is aggregation. This is where a retailer and an accountable operator start to look different. Storm should be able to identify the first router under its control, the address block used, the monitoring it applies and the point at which another carrier becomes responsible. The exact AS212280 footprint makes such an answer plausible. If the circuit remains in a wholesaler’s address space until much later, the proposal should say so. A customer should not assume that every service sold by Storm uses Storm-originated addresses.

The fourth stage is external reach. The frozen BGP view points to AS203214 as the immediate visible route and to AS208293 behind it. Storm should state whether this chain applies to the offered service; whether other providers carry outbound, inbound or backup traffic; whether local content takes a different path; and whether failure can be isolated without waiting for several organisations to coordinate.

The fifth stage is operations. The public website offers a general contact form, phone and email. RIPE publishes membership and abuse contacts. Neither publishes a dedicated network-operations telephone number, 24-hour support commitment, incident severity definitions, response targets or a status channel. The customer should obtain all of those before activation. A generic inbox is an entry point, not an incident process.

The final stage is evidence after installation. Storm and the customer should capture a baseline: round-trip time and loss to agreed local and international targets, traceroutes in both directions, throughput under controlled conditions, route origin, public-address behaviour, DNS performance and application transactions. The baseline should be repeated at peak time and during a scheduled failover. Otherwise, both sides will debate what “normal” meant only after an outage.

This workflow also exposes the value Storm can add even when it leases parts of the chain. A regional operator may know local civil routes, tower access, building owners, power conditions and field logistics better than a distant carrier. It can aggregate demand, hold spares nearby, translate a business outage into a precise upstream case and restore an access link faster. Those capabilities are not visible in BGP, but they are testable through references, maintenance records, dispatch targets and exercises.

The inverse is also true. Owning an ASN does not make a provider accountable for every layer. If field work is subcontracted, if the last mile belongs to another operator and if external routing has one active path, Storm’s ability to remedy a fault may be narrower than its branding suggests. A good contract does not pretend otherwise. It names dependencies and makes escalation measurable.

Continuity is a chain of clocks

Service continuity is often reduced to “99.9% uptime”. That percentage is almost useless without clocks attached to specific actions.

The first clock starts when monitoring detects a fault. Does Storm monitor the customer circuit from both ends, or does the customer have to report it? The second starts when a case is acknowledged. The third measures fault isolation: customer equipment, access link, power, aggregation, Storm core or upstream. The fourth measures dispatch. The fifth measures the upstream’s response. The sixth measures restoration, and the seventh the delivery of a cause report. A provider can meet a fast acknowledgement target while taking hours to identify which other party must act.

Public Storm material does not specify these clocks. It does not publish planned-maintenance notice periods, service-credit rules, a restoration target, spare-equipment coverage or an incident-communication cadence. That is a disclosure gap, not proof of weak operations. It shifts the burden to the proposal and contract.

Iraq’s operating environment raises the stakes. Internet Society recorded a government-directed national suspension on May 20, 2026, from 06:00 to 07:30 local time, as the first in an expected exam-period series. Its page reported 37 shutdowns in the preceding twelve months and 172 since 2018 at the time of access. No ISP can turn upstream diversity into a licence to disregard a lawful national restriction. A continuity plan can still distinguish between an operator-caused fault, a national restriction and a failure of the customer’s own site, then provide timely, accurate communication for each.

Power is a second shared dependency. The International Energy Agency’s Electricity 2026 reliability assessment records that temperatures near 50°C contributed to the shutdown of two Iraqi transmission lines and a nationwide grid collapse on August 11, 2025, with more than 6,000 MW suddenly lost. That national episode does not establish any Storm outage. It establishes why runtime claims need testing. An access radio, aggregation switch and core router can each have backup power while the customer site does not; or the customer can remain powered while an intermediate cabinet fails.

A useful Storm continuity schedule would therefore state:

monitored availability and performance targets at the service demarcation;
response, update, dispatch and restoration targets by severity;
power runtime at the customer hand-off, access and aggregation sites;
named upstream escalation commitments;
planned-maintenance windows and notice;
service credits that apply automatically from monitoring evidence;
a cause-report deadline for material incidents;
separate treatment of national restrictions and force-majeure conditions;
a quarterly or semi-annual failover exercise for critical customers.

For SMEs, human continuity can matter more than architectural elegance. If the network engineer who understands a customer’s static routes is unavailable, can another person access the configuration and carrier contacts? Are field teams staffed outside office hours? Does the support desk recognise business-critical applications, or only total loss of link? The public record cannot answer, and headcount claimed on a social platform is not a substitute. The procurement test should include an unannounced call to the supplied escalation number and a timed simulated fault before the service is accepted.

Security starts with the route, then moves inward

Storm’s valid route-origin authorisations are the clearest public security control. Its RIPE records also provide a dedicated abuse contact, which supports coordination when traffic from an address is implicated in misuse. Those are useful foundations.

The rest of the security posture is largely undisclosed. Storm’s website advertises cybersecurity solutions, and its company page lists network security and traffic engineering. Neither publishes a DDoS mitigation design, scrubbing partner, filtering policy, secure-management standard, vulnerability process, logging retention, incident-response commitment, certification or independent assurance. A company can operate effective controls without publishing them. A customer handling sensitive or regulated data still needs evidence under confidentiality.

The first security question is address control. Will the customer receive a public IPv4 address, shared address translation or a routed subnet? Are inbound ports filtered? Can source addresses be spoofed from the customer link? How are compromised devices contained? If the customer announces its own prefix, what route filters and maximum-prefix limits apply? These answers affect both exposure and portability.

The second is DDoS handling. Nine /24s with one visible immediate route can be protected upstream, on Storm’s edge, or by diversion to a scrubbing service. Public BGP does not reveal which. The proposal should state detection thresholds, automated and manual controls, clean-traffic capacity, supported attack types, customer notification, blackhole policy and whether mitigation changes latency or path. A paper claim should be followed by a controlled exercise or evidence from a previous anonymised case.

The third is management security. Managed routers and optical terminals create privileged access into customer sites. Buyers should ask how administrative access is authenticated, segmented, logged and removed; how firmware is maintained; how default credentials are prevented; and how configuration backups are protected. If Storm staff can change customer routes remotely, the customer needs an approval and emergency-change procedure.

The fourth is incident coordination. MANRS emphasises accessible, current contacts because route leaks and spoofing are not solved by cryptography alone. Storm has RIPE contacts but no public network-operations contact in PeeringDB. A contracted customer should receive a 24-hour security and routing escalation channel, with named backup roles and a method to authenticate urgent requests. Attackers can exploit an incident by impersonating a customer and asking for a route or DNS change.

The fifth is scope. Selling cybersecurity advice is not the same as securing internet access, and securing Storm’s edge is not the same as securing a customer’s applications. The contract should separate connectivity controls, managed-equipment controls, optional security services and customer responsibilities. Marketing language that collapses them into one “secure internet” promise creates ambiguity precisely when an incident occurs.

Regulatory scope also belongs here. A customer buying a security service alongside connectivity should ask Storm and the relevant regulator what authorisation applies rather than assuming that number-resource status or an internet-access licence covers the bundle. The safest rule is simple: verify each claimed service against the licence, staff, tools and insurance relevant to that service, rather than letting the strength of the routing evidence spill over into unrelated assurance.

Regulation: a RIPE membership is not an Iraqi ISP licence

RIPE NCC and the Iraqi regulator answer different questions. RIPE allocates and records internet number resources. Iraq’s Communications and Media Commission governs the authority to provide communications services in the country.

The CMC’s 2023 ISP licensing regulation establishes classes of internet-service activity and requirements for providers. The regulator’s later notice to ISP companies says providers in classes A, B and C must register their towers and license their microwave links. The CMC’s telecommunications service guide describes legal, technical and financial documents required for ISP licensing and renewal.

The public sources examined for this article did not provide a company-specific Storm licence certificate or a clear entry that establishes its current class and authorised geographic or service scope. That is not a finding that Storm is unlicensed: this evidence set is not an authoritative company-specific licence verification. It is a due-diligence item. A buyer should request the certificate directly, verify its legal name and number with the CMC, check its validity period, and ensure that the proposed access technology, towers, microwave links and service area fall within scope.

The distinction is commercially important. If Storm sells a link built on another licensed provider’s infrastructure, the contract should identify which party holds which authorisation. If Storm operates a tower or microwave hop, the relevant registration should match the path. If it supplies software or a managed security service alongside access, separate rules may apply. One certificate should not be assumed to cover the entire bundle.

Consumer and service-quality rights also need a route to enforcement. The CMC’s quality-of-service and spectrum page describes a national free complaint line, 177, and monthly complaint reporting for covered communications providers. A business contract should state its own escalation and dispute path first, then explain whether and how regulatory complaint procedures apply. Customers should not discover after a long outage that the named contracting company, infrastructure owner and licensed provider are different parties with different responsibilities.

Regulatory compliance is therefore part of continuity. An expired licence, unregistered microwave link or unclear subcontract can become an operational risk even when the routers work. The best evidence set aligns the RIPE legal name, CMC licence, contract, invoice, bank account, network diagram and support contacts. Storm already has a strong exact-name anchor in RIPE. The remaining task is to make the domestic authorisation equally legible.

The economics behind an unpublished price

Storm publishes no tariff card or standard service terms on its website. That suggests a negotiated sale, but it does not reveal how the price is calculated. A buyer should resist comparing quotes only by megabits per second.

The access component may include civil work, fibre, radio equipment, tower space, customer equipment and installation. The network component may include committed bandwidth, oversubscription, local traffic, international transit, public addresses, route management and mitigation. The service component may include monitoring, managed equipment, dispatch, support hours and restoration priority. Taxes, licence fees, power, spares and foreign-currency exposure can sit behind all three. Two 100 Mbps offers can therefore be economically different products.

Iraq’s official ICT industry white paper describes a fixed-broadband market divided among nationwide and regional network operators and end-user providers that lease capacity from them. It also describes the National Internet Project, a fibre backbone and access programme involving public infrastructure and private partners. This layered market helps explain why the retail provider, last-mile owner and upstream carrier may differ.

The same paper reports large historical differences in fixed-broadband speed tiers and geographic performance. Its figures are a country-level baseline, not evidence about Storm. They reinforce the need to price the actual site and service chain. A cheap link on an uncontended local path can perform well for domestic content yet struggle internationally; an expensive dedicated circuit can still share an unprotected building entry; a nominal backup can be worthless if it rides the same wholesale route.

The quote should separate one-time and recurring costs, define the committed rate in both directions, state whether traffic is shaped, explain contention, list included addresses, and price service upgrades. It should also specify what changes after the initial term. Installation subsidies can create an early termination charge; equipment can remain the provider’s property; a discounted first year can conceal a sharp renewal. None is inherently unreasonable if disclosed.

Switching cost deserves its own line. A customer using Storm-assigned public addresses may need to change firewall rules, remote-access allowlists, partner configurations and DNS when it leaves. Managed-router configuration may not be portable. A rooftop radio, fibre entry or building permission can tie the site to one access path. Historical performance data may sit only in the provider’s portal. The contract should grant configuration exports, monitoring records and a reasonable migration period.

For larger customers, provider-independent address space and multihoming can reduce lock-in, but they add routing and security complexity and are not justified for every SME. A simpler approach is application-level resilience: a second provider with a different physical and routing chain, cloud-based access controls that tolerate address change, tested cellular or satellite backup, and clear failover priorities. Storm should be evaluated on how well it supports that design, not on whether it captures every link.

Competition has become three-dimensional

Storm competes in more than a list of Iraqi ISP names. It competes against alternative access technologies, alternative operating chains and the customer’s option to combine them.

The first dimension is terrestrial fixed access. Iraq’s National Internet Project and private fibre deployments make FTTH and enterprise fibre the obvious benchmark where available. Storm’s self-reported FTTH and business-internet capabilities place it in that arena. The buyer’s comparison should focus on serviceability, route ownership, contention, restoration and upstream diversity rather than a headline speed.

The second is mobile and fixed-wireless access. National mobile operators can provide rapid deployment and a physically separate last hop, although radio congestion, coverage, address translation and indoor signal can limit business use. A local point-to-point wireless operator can reach sites where fibre construction is slow, but its towers, spectrum, power and line of sight become the critical chain. Storm lists wireless networking among its capabilities; it should specify which category the proposed link occupies.

The third is satellite. On July 17, 2026, the CMC announced that it had signed Starlink’s operating licence in Iraq, explicitly presenting satellite broadband as an expanded option, especially for places needing advanced alternatives. Commercial availability, package terms and performance still require separate confirmation. The regulatory step changes the procurement conversation: a satellite path may offer physical diversity from terrestrial ducts and towers, while introducing its own power, sky-view, weather, terminal and remote-support dependencies.

Storm’s strongest response need not be to own every technology. It can become the accountable integrator for a well-designed mix, provided it discloses whose network each link uses and proves that failures are independent. An SME may value one local team that manages fibre, wireless backup and routing more than three disconnected suppliers. But aggregation can also hide correlated dependencies. If both links eventually pass through AS203214, the bundle is not upstream-diverse.

Local peering is another competitive axis. Iraq’s exchange has content and network entities that can keep some traffic local, lowering latency and reducing transit demand. Storm’s public PeeringDB record does not show an exchange presence. A buyer whose applications depend on specific local platforms, cloud regions, payment systems or international software should test those destinations directly. “Connected to an exchange” and “good path to the application” are different claims.

The competitive winner will be the provider that makes its chain legible. Published facility presence, current routing contacts, transparent service terms, route diversity and measured performance reduce a buyer’s uncertainty. Storm has already done the hard technical work of operating authorised prefixes over years. Its public commercial and interconnection disclosures have not caught up with that footprint.

A procurement test that an accountable operator can pass

The best way to distinguish an operator from a reseller is not to ask, “Do you own your network?” Few regional services are wholly owned end to end. Ask for evidence at each control boundary, then create a failure that crosses it.

Begin with identity. The quotation, contract, CMC licence and invoice should use the exact legal name recorded by RIPE. The signatory should explain the relationship between that company, the Storm Network name and the Soft Storm branding. The proposed service should identify the originating ASN and address range. If another ASN or legal entity appears, require a written bridge before proceeding.

Next map the physical path. For primary and backup circuits, obtain separate diagrams showing building entry, access medium, aggregation point, Storm edge, upstream hand-off and power domain. Mark which assets Storm owns, which it leases and which another provider operates. Ask for enough route detail to establish separation without demanding sensitive street-by-street information. A declaration that links are “diverse” should name the first point at which they meet.

Then map routing. Capture Storm’s current nine-prefix origin set and the observed AS203214 path. Ask what the customer should see under normal operation and after withdrawal of that neighbour. If a backup upstream exists, schedule a maintenance window in which Storm moves a test prefix or the customer circuit to it. Observe inbound and outbound routes from multiple locations. Confirm that capacity, latency and loss remain within agreed degraded-mode targets.

Test the last mile independently. Disconnect customer equipment, remove the access signal, interrupt primary power under controlled conditions and verify alarms. For wireless, test interference and weather margin; for fibre, confirm optical thresholds and restoration spares. For a dual link, fail the primary at the demarcation and farther upstream. A design that succeeds only when the customer router is unplugged may still fail when the common aggregation site disappears.

Test people. Open a medium-severity case outside normal office hours using the supplied channel. Record acknowledgement, diagnosis, updates and escalation. Run a separate routing-security scenario: report a suspicious origin or route change and see whether the case reaches someone who can inspect BGP. Verify that contact details are role-based and have backups. Do not rely on a salesperson’s personal number as the continuity plan.

Test the applications. Select a local destination, a major international cloud service, the customer’s payment or communications platform, and a remote-access endpoint. Measure transactions, not just speed. A 100 Mbps link with intermittent loss can be worse for voice, remote desktops and payments than a steady 20 Mbps link. Repeat at peak time and during failover.

Test the contract against the evidence. Define where availability is measured; exclude only clearly described causes; attach response and restoration clocks; make credits automatic from shared monitoring; require notice of material upstream or topology change; and preserve the right to terminate after repeated severe failures. If the service depends on a named third party, Storm should remain the customer’s accountable interface even when the cause lies upstream, unless the contract clearly assigns another process.

Finally, set watchpoints:

any change in the origin of the nine current /24s;
appearance or disappearance of AS203214 as the immediate route;
activation of native IPv6;
publication of a facility or exchange presence;
a company-specific CMC licence record or updated certificate;
a dedicated network-operations and status channel;
evidence of a genuinely independent upstream;
a public explanation of significant outages or route migrations;
commercial availability of newly licensed satellite alternatives;
changes in Storm’s legal or operating-domain details.

This is not an adversarial exercise. A capable operator benefits when the customer understands the chain. The test prevents a later argument in which the provider says the failed component was outside its control and the customer says it believed the whole service was protected.

What the evidence establishes—and where it stops

The public case for Storm is stronger than its sparse website suggests.

The exact Iraqi legal entity is a RIPE NCC member and local internet registry. It is tied to stormnetwork.net through registry contacts and overlapping Baghdad details. Five ASNs sit under its current RIPE organisation record. Its registry and routing record stretches back to the 2015–16 creation of AS203811 and AS203459, while AS212280 has carried a visible prefix since 2020 and now originates nine /24s. Those current routes have valid origin authorisation. This is sustained network-resource and control-plane evidence, not a name assembled from an online directory.

The same evidence also draws a boundary. At the cut-off, AS212280’s nine visible prefixes presented one immediate external neighbour in the tested RIPE views. The representative prefix’s 333 paths all traversed AS203214 and AS208293 before reaching Storm. Public interconnection records showed no Storm facility, exchange connection or network contact. The company did not publish capacity, network geography, service levels, incident history, power design, support escalation, tariffs or a customer-verifiable resilience plan.

Some of those things may exist privately. BGP collectors cannot see dormant backup circuits, private interconnection, spare routers, field teams or contract terms. PeeringDB is voluntary. A website can lag a network. The correct conclusion is not that Storm lacks these capabilities. It is that a buyer cannot credit them until Storm supplies and demonstrates them.

Storm therefore occupies an interesting middle ground in Iraqi connectivity. It has enough independent routing authority to be accountable for origin policy and part of the customer path. It appears dependent, at least in the frozen public view, on a concentrated upstream hierarchy for global reach. Its opportunity is to turn that partial control into a transparent operating product: documented last-mile ownership, tested upstream failover, clear facility and power evidence, disciplined support, verified regulatory scope and contracts that describe the chain honestly.

For a buyer, the distinction between operator and reseller is not binary. It is a sequence of questions: Who owns the address? Who originates the route? Who controls the access equipment? Who can move traffic? Who holds the licence? Who dispatches at night? Who has the spare? Who calls the upstream? Who communicates when the whole country is intentionally disconnected? Who pays when the restoration clock is missed?

Storm can already answer the first two in public. The value—and resilience—of its service depends on how convincingly it answers the rest.