Summary

  • Foreach AS is active enough to analyse as a current service provider. The Norwegian business register identifies FOREACH AS as an active Trondheim private limited company, Foreach's own site is live, and RIPEstat saw AS214761 announcing both 195.191.30.0/23 and 2001:67c:1420::/48 on 12 July 2026.
  • The hosted-capacity claim is real but bounded. Foreach says it offers server and hosting for applications in cooperation with ITsjefen, and its data-processing terms name ITsjefen AS as the provider of web hosting, virtual servers, outgoing mail from those services and backup.
  • The main physical dependency is not hidden. ITsjefen publishes three Trondheim-region data centres, about 1,000 square metres of capacity, a multi-redundant 100 Gbps fibre network, facility power controls and named upstreams. Those claims support a local Norwegian hosting context, but they do not disclose Foreach's exact rack allocation, failover design, backup frequency or restore test history.
  • The routing layer is presently visible but concentrated. RIPE registry policy for AS214761 lists ITsjefen AS44381 and Underworld AS50213, while RIPEstat's neighbour view showed only AS44381 as the live visible neighbour at the cut-off. A customer relying on Foreach should therefore ask how traffic, support, backups and data export behave if the AS44381 handoff, an ITsjefen room, a specific host, or a Foreach support window fails.

A small consultancy with a visible network edge

Foreach AS is not a hyperscale cloud, a regional fibre carrier or a wholesale colocation operator. It is a small Norwegian IT company whose public identity starts with software development and day-to-day operations support. Its homepage says the Trondheim company consists of two experienced developers and consultants. Its services page describes custom system integration, software and development services, digitalisation advice, secure operation and hosting. The Norwegian business register record for organisation number 929687876 gives the legal name as FOREACH AS, records incorporation on 10 August 2022 and registration on 24 August 2022, classifies the activity as computer programming services, and shows the company as neither bankrupt nor under liquidation at the cut-off.

That scale matters. A small consultancy can be a strong hosting supplier for narrow, business-specific systems because the people who build the application may also know the customer's processes, integrations, failure habits and support expectations. The same scale can also concentrate risk. If the same two named people hold the customer context, the deployment knowledge, the local support channel and the commercial relationship, then a hosted application depends not only on a data centre but also on continuity of human attention.

Foreach's public site makes that combined role clear. The system-development page says the company develops web applications such as customer portals, intranets and APIs, and adds a distinct "server and hosting" line: Foreach offers server and hosting of applications in cooperation with ITsjefen. The IT operations and support page says Foreach assists with operation and maintenance of IT systems, support for technical problems, equipment purchasing and setup, and remote support for many cases. The cloud-solutions page lists cloud services for email, meeting-room booking, storage, backup and network access. This is not merely a brochure for code. It is a service envelope around hosted business functions.

There is also current internet-number evidence. The RIPE aut-num record for AS214761 names the AS as Foreach, links it to the Foreach organisation entity, and was created on 5 June 2024. The RIPE organisation record ORG-FA1308-RIPE names Foreach AS, gives Norway as the country and lists a Trondheim address. A RIPE search for 195.191.30.0/23 returns an inetnum entity for NO-FOREACH-AS, status ASSIGNED PI, organisation ORG-FA1308-RIPE and maintainer ITSJEFEN-LIR. Those are strong administrative signals: Foreach has its own routed address space and autonomous-system identity, while ITsjefen maintains the registry entities around it.

The operating evidence goes beyond records. RIPEstat's announced-prefixes view for AS214761 showed 195.191.30.0/23 and 2001:67c:1420::/48 announced through the 12 July 2026 cut-off. RIPEstat's IPv4 routing-status result showed the IPv4 prefix visible to all 327 IPv4 RIS peers, and the IPv6 routing-status result showed the IPv6 prefix visible to all 322 IPv6 RIS peers observed by that service. Public DNS also tied Foreach's own website to its routed space: a lookup for foreach.no returned 195.191.30.65, and IPinfo's page for that address associates it with AS214761 Foreach AS in Trondheim.

That combination gives Foreach a more tangible network edge than many small software consultancies. It does not prove the size of its server fleet, its customer count, its storage volume or the uptime of each application. It does prove that Foreach's public web presence and its allocated address resources were reachable through a current BGP announcement at the assessment date. For a company whose public offer includes hosted applications, that is enough to ask a real infrastructure question instead of treating the hosting line as a vague partner label.

The hosted offer is a managed application service, not raw cloud capacity

Foreach's customer material points toward managed, application-specific hosting rather than commodity self-service cloud. On its customer page, the company says it develops and operates systems for iBOKS Minilager, Tunga Bil, NORoption and Terminalen Rigg. The examples are operationally specific: iBOKS has a storage-rental system with a backend, API, third-party integrations, administration portal and customer "My page"; Tunga Bil has an overview system for customers, vehicles and documentation; NORoption has service-agreement and installation records; Terminalen Rigg uses systems for booking, check-in, rooms, occupancy and invoicing integration. The exact hosting arrangement for each named customer is not disclosed, but the pattern is clear. Foreach's value is not only virtual machines. It is the combination of custom application logic, support and hosted continuity.

That is economically different from a public cloud account. A customer buying an application from Foreach may not care which hypervisor runs it, which switch carries the packets or which backup target stores the copies, until something fails. At that moment, the small managed provider has to bridge layers that a self-service cloud customer might manage separately: application code, server operating system, storage, network reachability, authentication, third-party integrations, billing and customer support. The customer is buying reduced complexity, but the complexity still exists somewhere.

Foreach's data-processing agreement is the most explicit document for this chain. It says Foreach may process personal data for customer follow-up, sales and service delivery; it lists stored categories such as contact details, subscription data, order data, invoice and payment history, logs, login details, storage data and resource usage; and it names four subprocessors. ITsjefen AS is listed as the provider of server services used by Foreach, including web hosting and virtual servers, plus outgoing email from those services. The same paragraph says ITsjefen is responsible for backup of those services. Fiken AS is listed for accounting, Teletopia Interactive AS for SMS sending, and Microsoft Ireland Operation for email service.

This is useful because it locates responsibility without overstating ownership. Foreach offers hosted applications and can control much of the software layer. ITsjefen supplies the physical and virtual server layer that Foreach says it uses. Microsoft handles email service, while accounting and SMS sit with other named suppliers. If a Foreach customer experiences a service failure, the answer might sit in Foreach code, Foreach configuration, ITsjefen compute or storage, an ITsjefen backup process, Microsoft email, a telecom SMS path, or a third-party business integration.

The customer sees a Foreach service; the actual recovery path crosses several companies.

The agreement also contains a locality promise with limits. It says Foreach must be able to document where personal data is stored and that personal data should not be transferred outside the EU/EEA without necessary safeguards. That supports the "data sovereignty and locality" topic, especially when paired with ITsjefen's Norway-based cloud claims. It does not say that every customer workload stays in one room, that every subprocessor stores all data only in Norway, or that backups are isolated from the primary service. Those details would have to be confirmed in a customer-specific contract, data map and restore plan.

The strongest public conclusion is therefore narrow: Foreach sells managed hosted application capacity, and it publicly links that capacity to ITsjefen's server services. The weakest public conclusion would be to call Foreach a data-centre operator. The company's own wording points elsewhere. Foreach is the application and customer-facing operator; ITsjefen is the disclosed server-services provider; the infrastructure risk lives at the boundary.

The physical boundary runs through ITsjefen's Trondheim rooms

ITsjefen's public material gives the clearest view of the racks, power and fibre that can sit under Foreach's service. ITsjefen's services page says the company, part of ECIT, provides data-centre, IT operations, infrastructure and security services. Its about page says ITsjefen has operated since 2004, has 22 employees, runs three data centres in the Trondheim region with about 1,000 square metres of total capacity in its own premises, can offer data-centre services in Oslo through a group facility, and operates its own racks in Stockholm and London. It says employees support customers around the clock through various operations and support agreements.

The ITsjefen data-centre page says the Trondheim-region portfolio is tied together by a multi-redundant 100 Gbps fibre network. It describes the facilities as designed for redundancy, monitoring, certified operation and flexible hosting, and lists redundant power, cooling, UPS, diesel generators, camera monitoring, climate monitoring and gas-based fire suppression. A small provider that hosts with ITsjefen can therefore inherit a serious facility base without owning a building or running power plant itself.

The individual site pages add material detail. NDC2 has been operated by ITsjefen since 2008, uses a closed cooling circuit to Trondheimsfjorden for the primary cooling loop, has redundant fibre connections using different routes in central Trondheim, individual A/B UPS units, a diesel generator and redundant air cooling. The page says it has been TIA-942-A and EN50600 certified since 2016 and ISO27001:2022 certified in August 2025. It also names AS44381, two 100 Gbps backbone connections, 10 Gbps peering at TRDIX and 10 Gbps upstreams from Telenor, Telia and GlobalConnect.

NDC3 is described as a high-priority data centre with EMP protection for critical solutions, redundant fibre connections, individual UPS units, a diesel generator and redundant cooling. It is not a generic room for every ordinary hosted application; the page says access is limited to specially cleared personnel at ITsjefen and the customer. NDC4 is more directly relevant to capacity: ITsjefen describes it as about 600 square metres, more than 600 square metres in the headline, with 2 MW capacity, below ground level at Tungaveien 30, outside flood, landslide and quick-clay risk areas by reference to NVE maps, certified ISO27001:2022, EN50600 Tier III and TIA-942A, with A/B cooling and power sides, UPS, diesel generator, four separate fibre entrances from five internal routes, customer zones and 24/7 access for customers with whole racks.

These are strong provider-level claims. They make Foreach's hosted offering materially different from a laptop under a desk or a single rented virtual server in an unknown market. They also stop short of Foreach-specific redundancy evidence. The public record does not say which ITsjefen room Foreach uses, whether Foreach has equipment in more than one site, whether the 195.191.30.0/23 and 2001:67c:1420::/48 traffic can move between rooms without customer impact, which storage platform holds Foreach backups, how often restore drills run, or whether Foreach has a tested exit from ITsjefen to another hosting provider.

That distinction is the core of the physical-dependency analysis. ITsjefen may have redundant rooms, redundant power and multi-path fibre; Foreach may still have a single production instance, a single storage pool, a single backup policy or a single support escalation path for a given customer. Facility redundancy is necessary but not sufficient. Hosted application resilience depends on how Foreach consumes the facility service, how it separates customers, how it replicates data, and how it performs a restore when a concrete failure arrives.

Routing is live, but observed diversity is narrower than the policy file

AS214761 is not dormant. The current route evidence is among the strongest parts of Foreach's public infrastructure profile. RIPEstat saw the IPv4 and IPv6 prefixes announced at the cut-off, and RIPEstat's BGP-state sample for AS214761 showed many observed paths ending in AS44381 and AS214761. That is a live internet path, not just a registration.

The dependency question is in the next hop. RIPEstat's neighbour view for AS214761 showed one unique neighbour on 12 July 2026: AS44381. The RIPE aut-num policy for AS214761 lists imports from AS44381 and AS50213 and exports to both. The difference matters. Registry policy can describe intended or permitted relationships; public route collectors show what they observed. At the cut-off, the observed relationship visible through RIPEstat was ITsjefen AS44381.

ITsjefen itself is much broader. The RIPE aut-num record for AS44381 shows a network with multiple imports and exports, including Telenor AS2116, Telia AS2119, GlobalConnect AS25400 and several customer or peer relationships. RIPEstat's announced-prefixes view for AS44381 showed nine prefixes at the cut-off, while the AS44381 neighbour view showed twelve unique neighbours. PeeringDB's AS44381 entry describes ITsjefen as a network service provider with open general peering policy, though it did not list facility or exchange LAN attachments in the returned API entity. ITsjefen's NDC2 and NDC4 pages separately claim TRDIX peering and 10 Gbps upstreams from Telenor, Telia and GlobalConnect.

For Foreach customers, this creates a two-level routing picture. Upstream of ITsjefen, there is evidence of multiple carriers and a richer AS44381 network. At the Foreach edge, there is one observed live neighbour. A single observed neighbour does not prove one physical fibre or one router. It can represent a managed BGP service delivered over redundant physical paths inside ITsjefen's network. But it does mean the customer's public path to Foreach's prefixes appears to pass through ITsjefen as the visible provider.

If ITsjefen's customer handoff to Foreach, a Foreach router, a route filter, or the AS44381-to-AS214761 policy breaks, the published prefixes can disappear even if the data-centre building has power and the application servers are healthy.

The 195.191.30.0/23 route history reinforces that this space has moved through ITsjefen's control. A RIPE search for the prefix still returns an older route object whose origin is AS44381 and whose description includes Doghouse AS, Trondheim, Norway. The live routing-status service, however, shows origin AS214761 at the cut-off. That suggests Foreach's current announcement is now distinct, while ITsjefen remains the maintainer and upstream context. It is a plausible local network arrangement for a small service provider: the customer-facing company obtains provider-independent resources, the local data-centre and network operator maintains and carries them, and the customer's route is visible globally through that provider.

The unproven part is failover. The public record does not show Foreach announcing AS214761 through a second independent upstream at the same time, nor a route collector seeing AS50213 as a current left-side neighbour for Foreach. AS50213's RIPE record and RIPEstat neighbour view show Underworld AS50213 connected to AS44381, which makes it more likely to be part of the local routing ecosystem than an independent global escape route. That is not a criticism; it is a boundary. The currently visible Foreach path is active, but its public evidence supports "routed through ITsjefen" more strongly than "independently multi-homed."

Installed capacity is not the same thing as usable hosted capacity

Foreach's address resources can make the company look larger than its disclosed team, but address space is not server capacity. A /23 gives 512 IPv4 addresses before reservations and operational choices; an IPv6 /48 is more than enough to number many services cleanly. Those resources help a hosting provider separate services, assign customer endpoints, run dual-stack connectivity and avoid dependence on provider-assigned addresses. They do not state how many physical hosts, CPU cores, storage arrays, backup targets, staff hours or support windows are available.

The live website demonstrates the point. foreach.no resolves to 195.191.30.65, inside Foreach's announced /23, and IPinfo places that address under AS214761 in Trondheim. That is good evidence that Foreach uses its own routed space for a public service. It tells us very little about capacity headroom. The same address could front one site, many virtual hosts, a load balancer or a reverse proxy. A customer application could sit beside it, behind it, or elsewhere in ITsjefen infrastructure. Public DNS cannot answer those questions.

ITsjefen's data-centre capacity likewise needs careful translation. NDC4's 2 MW and 600-plus square metres describe a facility resource. They do not describe Foreach's allocation. If Foreach rents virtual servers, it may never control a whole rack, let alone a dedicated customer zone. If it has its own hardware, the public record still does not reveal rack count, storage redundancy, maintenance entitlement or onsite spare inventory. If it relies on managed ITsjefen server services, the recovery path may be written in the Foreach-ITsjefen contract rather than in equipment owned by Foreach.

Hosted application capacity also differs from raw compute. The iBOKS example on Foreach's customer page says the system supports access to storage rooms year-round, with a backend, API, third-party integrations, administration portal and customer page. The Terminalen Rigg example concerns booking, check-in, room overview, occupancy and invoicing integration. These are not workloads where capacity is measured only in Mbps or vCPU. A usable service also needs working integrations, authentication, payment or invoicing links, accurate data, scheduled jobs, support contact and customer communication during incidents.

This is where hosting economics become visible. A small provider can keep costs sensible by using a local data-centre partner, shared operating expertise and a small team that understands each customer. That can produce better practical support than a generic cloud ticket queue for a local SME. But the same economics can limit overbuild. Maintaining a warm standby environment, a separate second provider, spare hardware, regular restore exercises, customer-specific runbooks and 24-hour staffing all cost money. The public site does not say which customers pay for which level of continuity.

The right reading is not that Foreach lacks capacity. It is that the public evidence verifies reachability and a provider relationship, not usable failover capacity. Foreach's AS and prefixes are real. ITsjefen's data-centre portfolio is real enough to ground the physical dependency.

But a customer deciding whether to place a booking system, storage access service, service-contract system or operational portal on Foreach still needs service-specific answers: where is the production service, where is the backup, how quickly can it be restored, what happens during ITsjefen maintenance, who authorises data export, and which functions can run degraded?

Repair windows are a human system as much as a facility feature

The most ordinary failures are often the most revealing. A disk fails. A virtual host runs out of space. A backup completes but cannot restore a particular table-like data set cleanly. A certificate renewal breaks an integration. An invoice dispute suspends a component. A switch maintenance window causes packet loss. A customer's administrator leaves and no one can approve a DNS change. None of these events is dramatic enough for a public announcement, but each can interrupt a hosted application.

Foreach's about page names Audun Saether and Kenneth Grotdal, describes long experience in development, IT operations, backend development, programming languages, data stores, project management and customer handling, and provides direct email and phone contacts. For a small customer, that can be a major advantage. The people designing the system may be reachable, and the support conversation can begin with business context rather than a generic ticket form.

The IT operations page says many cases can be solved quickly through remote support and that Foreach can assist with purchasing and setup of PCs, network equipment, wireless networks, printers and upgrades, with fast delivery via known suppliers including Iteam and ITsjefen. That tells us Foreach thinks of support as practical and hands-on, not only code changes. It also shows supplier dependency in hardware stock. If replacement equipment, access to ITsjefen staff, or a specialist skill is unavailable, the repair window can lengthen.

ITsjefen's own support scale is larger. Its about page says 22 employees operate the three Trondheim-region data centres and support customers 24/7 through agreements. Its contact page gives ordinary opening hours of 08:00 to 16:00 on weekdays, while other pages advertise monitoring and duty arrangements. The difference between office hours and contracted duty service is important. A Foreach customer should not infer 24/7 application recovery merely because ITsjefen offers 24/7 support under some agreements. The actual entitlement depends on the contract chain: customer to Foreach, and Foreach to ITsjefen.

Repair also depends on authority. If a server fails inside ITsjefen, can Foreach restart, rebuild or move it directly, or must ITsjefen act? If an IP route changes, who controls the filter? If a backup must be restored, who approves overwriting customer data? If Microsoft email is degraded, does Foreach have an alternate customer contact route? If an SMS subprocessor fails, can the hosted application continue without SMS, or is login, access control or customer notification blocked? The public documents identify the suppliers but not the incident decision rights.

That uncertainty is not unusual for SME managed services. It is the nature of buying a compact service from a company that combines development and operations. The resilience test is whether the provider can turn informal knowledge into repeatable recovery. For Foreach, public evidence supports experienced people and a credible infrastructure partner. It does not reveal staff redundancy, named escalation times, spare-stock commitments, tested restores or customer-specific continuity options. Those are the questions that separate a good local service from one that works only while the original builder is available.

Data locality is a real selling point, but locality is not portability

ITsjefen's cloud page makes a clear Norwegian-locality pitch. The Skytjenester page says customers can meet public requirements for accountable, safe operation with Norwegian employees in Norwegian data centres, fixed agreed terms, clear delivery frames, and EN50600- and ISO27001:2022-certified data centres. It positions this against cost and compliance pressure in public cloud. For Foreach, whose data-processing terms name ITsjefen for server services and backup, that gives the hosted application offer a credible Norwegian data-centre anchor.

Norwegian location can matter for customers handling personal data, regulated records or politically sensitive operations. The Norwegian government's data-centre strategy, "Norwegian data centres - sustainable, digital powerhouses", presents data centres as part of the country's digital infrastructure and industrial policy. The updated data-centre strategy document says data storage and processing in Norway should be based on renewable energy and energy-efficient operations. Those are national context points, not Foreach-specific guarantees, but they explain why local cloud language can have commercial value.

Security guidance also supports asking more than "is it in Norway?" The Norwegian National Security Authority's basic ICT security principles are relevant to Norwegian organisations and to customers buying ICT services. Digdir's summary of NSM's principles says the recommendations can be used in one's own organisation and when buying ICT services. The point is practical: outsourcing a system does not outsource the customer's need to understand dependencies, recovery and controls.

European privacy guidance points in the same direction. The European Data Protection Board's Opinion 22/2024 on processors and subprocessors stresses that adding a subprocessor adds another link to the processing chain, and that approved subprocessors should be identified in the contract or an annex. Foreach's public agreement does list subprocessors, which is a positive transparency signal. The remaining question is operational: where are backups, logs, email, SMS records and exported customer data held during normal use and during recovery?

Cloud risk guidance turns locality into portability. ENISA's cloud computing risk assessment identifies cloud benefits and key risks, including loss of governance and lock-in. The UK government's guidance on managing technical lock-in in the cloud says exit strategy should balance the impact of changing provider against the benefit of staying. Those principles apply even when the provider is local and trusted. If Foreach builds a highly tailored application for a customer, the customer may be locked in through custom code, data shape, integrations, support knowledge and contract terms, not only through cloud APIs.

Locality, then, is valuable but incomplete. A Foreach customer can reasonably prefer a Trondheim-linked provider and Norwegian data-centre chain. It should still ask how data can be exported, how long Foreach retains backups after termination, whether backups can be restored to a different provider, whether Microsoft and SMS dependencies are covered by the same locality expectations, and how a failed provider contract would be unwound without losing access to the hosted application. Data sovereignty is a control surface, not a magic word.

The main failure path runs from rack to contract

The assignment for this company is to test a rack, upstream, hardware-stock, support, billing, migration or provider-contract failure. For Foreach, those are not separate scenarios; they are a chain.

A rack or room failure begins in the ITsjefen layer. The public facility pages describe redundant power, cooling, UPS, diesel generation, fibre routes and monitoring. If the affected Foreach service is truly deployed across redundant infrastructure, the customer may see little or no outage. If it sits on one host, one storage volume or one room, the service may depend on a restore. Public sources do not identify which design applies.

An upstream failure begins at the routing boundary. AS214761 is live, and AS44381 has multiple upstreams. If one ITsjefen upstream fails, AS44381 should in principle have alternate paths. If the AS44381-to-AS214761 relationship fails, or if Foreach's route policy is withdrawn, the Foreach prefixes can be unreachable even while the application is running. The visible neighbour count for AS214761 gives no public proof of a simultaneous independent second path.

A hardware-stock failure sits between the two companies. Foreach says it can procure and set up equipment and can use suppliers such as Iteam and ITsjefen. ITsjefen offers customer zones, whole-rack access and follow service for customer equipment in some contexts. But the public record does not say whether Foreach maintains ready spare servers, network equipment, power supplies, disks or optics for its hosted workloads. If a failed part must be ordered after the incident starts, recovery can become a logistics problem.

A support failure is human. Foreach's two-person structure may be agile, but availability of the right person matters. ITsjefen has a larger team, but the customer's contract may run through Foreach rather than directly through ITsjefen. If a customer cannot reach Foreach, cannot authorise a restore, or does not know whether to contact Foreach, ITsjefen or Microsoft, downtime extends. Public contact information is clear; public service-level detail is not.

A billing or provider-contract failure can be quieter than a power fault. If Foreach's server-services relationship with ITsjefen changes, the customer may need migration, re-addressing, data export, DNS changes, new backup targets and a new support path. If a customer stops paying Foreach or disputes an invoice, access to application data, backups and export support becomes a contractual issue. Foreach's public data-processing terms say that on termination Foreach must return or delete personal data according to the customer's instruction and confirm deletion or return.

That is useful, but it does not define the technical migration timeline for a complex application.

The recovery task is therefore not only to verify that a data centre has redundant power. It is to verify multi-site capacity, restore paths, transit diversity, support escalation and data portability. The public evidence confirms some of the provider-level pieces and much less of the Foreach-specific implementation.

The next evidence that would strengthen the assessment would be a customer-facing uptime and restore statement, backup frequency and retention terms, a statement of whether Foreach services can run from more than one ITsjefen site, a tested export format, an escalation path for out-of-hours incidents, and a statement of what happens if Foreach or ITsjefen terminates the hosting relationship.

Who is affected when the hosted chain breaks

Foreach's named customer examples make the impact concrete without requiring guesses about current production topology. If a storage-rental system like the one described for iBOKS is unavailable, customers may have trouble accessing account functions, and operators may have trouble administering rentals or access-control integrations. If a vehicle dealer's internal operating system is unavailable, staff may lose visibility into customer, vehicle and work documentation. If a service-contract system like the NORoption example is unavailable, field-service planning and history can be disrupted.

If a lodging and canteen provider's booking and check-in system is unavailable, reception, room overview and invoicing can suffer.

Those examples do not prove that each named customer's current production service is hosted in the same way or still active on Foreach infrastructure. They do show the category of effect. Foreach builds operational systems, not only informational websites. A hosted-capacity failure can interrupt physical-world routines: storage access, room booking, service visits, invoice integration and customer self-service.

Small-business customers often choose a provider like Foreach because they want one party that understands the business and can adapt the system. That same convenience can make the provider a bottleneck during an incident. A cloud console, source repository, backup export, DNS account, SMS account and accounting integration may all be understandable to Foreach but opaque to the customer. If recovery depends on specific people, the customer needs a plan for weekends, holidays, illness and supplier disputes.

Foreach can reduce that risk by publishing or contracting clear operational boundaries. Customers should know which functions run in ITsjefen facilities, which functions use Microsoft, which functions use SMS, where backups live, how long logs are retained, who can approve a restore, how to export data, and what minimum information Foreach needs to rebuild service elsewhere. Public documents already identify many supplier names. The remaining gap is not whether the suppliers exist; it is whether customer-specific services can survive a failure of one supplier or one contract.

The affected party is also Foreach itself. Because its own website resolves inside AS214761, a routing or hosting failure can affect its public sales and support surface at the same time as customer applications. If email remains on Microsoft, customers may still reach Foreach by mail even when the Foreach prefix is down; if telephone support remains independent, there is another contact path. That separation is valuable. It should be intentional, documented and tested, because customers will not care which layer failed while their service is unavailable.

The operating-status assessment is active but bounded

Foreach AS passes the current-operations threshold. The company is active in the Norwegian business register, its website and contact page are live, it publishes current service material, it names customers and products, it has current RIPE organisation and AS records, and RIPEstat saw its IPv4 and IPv6 prefixes announced globally on the cut-off date. That is far stronger than a stale directory listing.

It does not pass a high-confidence redundancy threshold. The public evidence shows an ITsjefen-hosted dependency, an active Foreach AS, and a capable Trondheim data-centre provider. It does not show Foreach's production architecture, site distribution, backup isolation, restore tests, exact customer workloads, contractual service levels, spare-stock plan, or an independently observed second Foreach upstream. Those are not minor details for hosted applications; they determine whether an incident is a momentary failover, a planned restore, a long repair window or a painful migration.

The most useful way to classify Foreach is therefore "small managed application provider with real routed infrastructure and a disclosed local hosting partner." That classification gives credit where the evidence is strong and keeps caution where evidence is missing. Foreach is not merely a consultancy with a cloud slogan. It operates services in its own routed address space and publicly relies on ITsjefen for server services and backup. But it is also not proven as a multi-site cloud platform in its own right.

For customers, the practical due-diligence conversation should be specific. Ask which ITsjefen site hosts the service. Ask whether there is a second site or only backup. Ask how often restores are tested. Ask whether AS214761 can be announced through a second provider if AS44381 fails. Ask whether the customer's data can be exported in a documented format. Ask what happens if Foreach is unavailable for a day. Ask what support applies outside weekday office hours. Ask whether Microsoft, SMS and accounting dependencies degrade gracefully or block core functions.

Foreach's advantage is local knowledge tied to a credible Trondheim infrastructure partner. Its exposure is the same tie. Hosted capacity still depends on racks, transit, power, backup, contract terms and the people who know how to repair the service. The public evidence grade is Medium: current routing and provider facts are strong, while customer-level redundancy and portability remain unproven.