PT. INDONESIA SUPER CORRIDOR - DATA CENTER has to prove whether marketed data-centre capacity can survive power and carrier constraints

Summary

• PT. INDONESIA SUPER CORRIDOR - DATA CENTER has unusually concrete public signals for this batch: the ISC site markets a 550-rack Tier IV Data Center ISC MPR in Mampang Prapatan, the ISC about page says the company built network and data-centre capacity in Cyber 1, and Uptime Institute's client page lists issued awards for ISC Datacenter DPR, ISC Data Center Cyber-1 Building CBR Level 9 and Data Center ISC MPR.
• The routing footprint is real but narrow. APNIC RDAP names AS142379 as ISC-DC-AS-ID for PT. INDONESIA SUPER CORRIDOR - DATA CENTER, and RIPEstat showed six current IPv4 /24 announcements with full RIS IPv4 visibility on 12 July 2026, but no current IPv6 visibility and only one observed AS neighbor.
• The main diligence gap is not whether an ISC-branded data-centre business exists. It is whether the advertised rack, cloud and disaster-recovery offers have enough disclosed utility feeds, generator runtime, cooling redundancy, meet-me diversity, customer failover tests and exit procedures to support production workloads when power, carrier or facility conditions become uncomfortable.

ISC is a stronger case than a directory placeholder

Some infrastructure profiles start from a thin registry entry and never get much further. PT. INDONESIA SUPER CORRIDOR - DATA CENTER is different. The company is visible in the BTW directory, on its own public service pages, in Uptime Institute's awards database, in PeeringDB records around its exchange and organisation, and in live routing observations. That does not make the operating case complete, but it changes the question. This is not a search for a building that may not exist. It is a test of how much trust should be placed in a marketed data-centre platform whose public record is stronger on facilities and product packaging than on measured customer recovery.

The ISC home page leads with a specific claim: "550 racks available in Tier IV Data Center ISC MPR (5MW), Mampang Prapatan Raya, Jakarta, Indonesia." It also advertises 100 Mbps IIX and 10 Mbps IX, 10A power, a /29 public IP allocation and two UTP plus two fibre cross-connects for the full-rack style offer. The same page says the facility is secure, manned around the clock, protected by CCTV motion detection, and accessible through PIN and card controls. Those are not vague cloud adjectives. They are rack, power, cross-connect and physical-access claims.

The about page adds the older Cyber 1 context. ISC says it began by building its own network and data centre in Cyber 1, Jakarta, and describes the original proposition as a reliable, multi-homed managed network inside a facility with high uptime. It also says the company maintains PCI DSS responsibilities when it stores, processes or transmits cardholder data for customers. The same page says ISC is located in the centre of Indonesia's internet exchange environment, claims dual-source power resilience via a separate distribution board, and positions its services around Tier III facility quality. Again, this is a physical-infrastructure story: location, power distribution, network reach and compliance obligations.

Uptime Institute gives independent shape to that story, though not a complete operating verdict. Its client page for PT Indonesia Super Corridor lists three sites with issued awards: ISC Datacenter DPR in Denpasar, ISC Data Center Cyber-1 Building CBR Level 9 in Jakarta, and Data Center ISC MPR in Jakarta. The Uptime country awards list for Indonesia places ISC alongside other certified Indonesian facilities. A buyer should still read award type and scope carefully, because Uptime's own tier-certification material distinguishes design, constructed facility and operations certifications. But the award database does support the premise that ISC has facilities worth evaluating, not merely a brand page.

This makes the assignment's operating-status caution more useful, not less. When public evidence is thin, the answer is often "do not rely on it." When public evidence is concrete but uneven, the better answer is "separate what exists from what can be survived." ISC's public record supports facility existence, service marketing, an exchange-facing network role and active IPv4 routing.

It does not publicly prove every customer-critical detail behind marketed capacity: actual occupied racks, reserved power, generator fuel contracts, diverse carrier entrance paths, cooling failover tests, historical incident handling, backup independence, or the difference between cloud capacity sold by ISC and customer equipment merely housed in ISC space.

The asset map has three named facilities, not one generic data room

ISC's own navigation splits the data-centre story across CBR, MPR and Bali disaster-recovery pages. The Data Center Tier III CBR page markets colocation per U, half-rack and full-rack offers with a 99.982% service-level figure, IIX and IX bandwidth, IP allocation, access rights, traffic monitoring, smart-hands support and DCIM accounts. The full-rack package on that page advertises 100 Mbps IIX, 10 Mbps IX, a /29 public IP range, five data-centre user accesses, two UTP cross-connect ports and two fibre cores. This is the Cyber 1-facing legacy part of the ISC story.

The Data Center Tier IV MPR page carries the higher-availability pitch. It advertises a 99.995% service-level figure for colocation per U, half-rack and full-rack packages, repeats the IIX/IX and content-cache language, and adds cloud business and cloud enterprise offers. Those cloud packages claim 1 Gbps IIX, OIXP and Equinix IX connectivity, up to 4 GB or 32 GB of memory, up to 80 GB or 640 GB of storage, one public IP, one Linux OS, a 1 Gbps port and up to 30 Mbps international bandwidth. That bundle matters because it turns ISC from a colocation-only company into a hosted-infrastructure provider whose customers may rely on ISC-operated compute, network and storage, not only their own equipment.

The DRC Tier III Bali page gives the recovery angle. It frames the Denpasar facility as a disaster recovery centre, advertises RPO and RTO concepts, describes gigabit connections to multiple exchanges, interconnected fibre optic design, resilient power from two different voltage sources and full backup generator capacity, FM200 and smoke detection above and below the raised floor, 24/7 CCTV, card and fingerprint access, and precision air conditioning with a redundant system. Those are useful claims because they identify the failure paths the company knows customers will ask about: failed primary infrastructure, fibre interruption, power interruption, fire and cooling.

Third-party facility directories support the existence of multiple ISC sites while introducing capacity noise that buyers should not ignore. Baxtel's ISC company page describes ISC as operating two data centres across one region and lists 6 MW, while its ISC Tower page describes the MPR site as a Tier IV data centre in South Jakarta with 550 racks and claims true 2N UPS dual-path resilience, diesel generators and IPv4/IPv6 support. Datacenters.com lists three Indonesia locations for ISC, and its MPR page reports 6,500 square feet, 1,791 square feet of raised floor and 16.0 MW of power. Those figures do not line up neatly with ISC's own 5 MW headline or the LinkedIn-style market signal that describes up to 8 MW of IT load. The inconsistency is not proof of misstatement; third-party directories can lag, estimate or mix building power with IT load. It is, however, exactly why customers should ask for a dated capacity schedule.

The useful conclusion is that ISC should not be reduced to one asset. CBR, MPR and Bali DRC appear as distinct parts of the public story. The risk is that public pages blur their operating boundaries. Which racks are in Cyber 1? Which cloud packages are delivered from MPR? Which workloads can actually fail over to Bali? Are the advertised exchange connections available in each room or only through ISC's broader network?

If a customer buys "Tier IV" service, is every dependency in the service path inside that Tier IV scope, or do management portals, support systems, upstream circuits, billing and backup repositories sit in other rooms? These questions define usable resilience.

Marketed capacity needs a conversion factor

The headline "550 racks available" is powerful because it gives a tangible scale. A buyer can imagine cages, cabinets, cross-connects, power whips and customer deployments. But data-centre capacity is never just rack count. The useful capacity is the amount of space, power, cooling and network handoff that can be sold without oversubscription turning into outage risk.

ISC's own MPR page helps illustrate the conversion problem. A full-rack offer includes a 10A power source, a /29 public IP allocation, traffic monitoring, smart-hands service, two UTP ports and two fibre cores. That is a practical bundle for enterprise colocation, but it does not equal a statement that every one of 550 racks can draw 10A continuously, that all racks have the same power density, or that enough cooling and upstream bandwidth exists for every rack to operate at modern AI or dense storage loads. A traditional enterprise rack at modest density is very different from a GPU or high-performance storage rack.

The public ISC pages do not publish density limits, PUE, cooling design temperatures, power-usage caps, breaker policies or actual sellable IT load by phase.

The same caution applies to the cloud packages. The MPR and CBR pages advertise "Cloud Business" and "Cloud Enterprise" with 99.9% service-level figures, memory and storage limits, one public IP, one Linux OS, 1 Gbps port language and up to 30 Mbps international bandwidth. Those terms sound smaller than the rack offers and may be aimed at ordinary business workloads rather than large-scale compute. A cloud VM can be provisioned from a resilient facility, but customer resilience depends on host clustering, storage replication, backup placement, live migration capability, snapshot export, maintenance policy and network path.

The public product pages show service packaging; they do not show the architecture under the virtual machines.

In the current data-centre market, power is the most important conversion factor. The IEA's Energy and AI report projects data-centre electricity consumption growing much faster than overall electricity demand through 2030. The pressure is global, but it lands locally: each building needs a utility connection, switchgear, UPS capacity, cooling capacity, generator support, fuel logistics and permission to expand. ISC's 5 MW MPR headline is meaningful in that context, but it is not enough. Customers need to know whether that number is utility capacity, building capacity, IT load, future design capacity or currently sellable committed capacity after existing customers, redundancy margins and maintenance headroom are subtracted.

ISC could remove much of the ambiguity with boring disclosure: total utility feed capacity, committed IT load, available sellable load, average and maximum rack density, UPS topology, generator fuel runtime, refuelling contracts, maintenance bypass design, cooling redundancy and the assumptions behind the 99.995% MPR figure. The public pages advertise dual-source power and backup generators in several places. That is a starting point. It is not the same as a customer-ready capacity model that shows what happens when one utility source, one UPS module, one cooling unit or one fuel delivery path is unavailable.

This is why the operating thesis should be upgraded from "thin public footprint" only for existence, not for resilience. ISC has a visible footprint. The downgrade sits at the point where marketed capacity has to become audited capacity. If a buyer is placing ordinary colocation gear with modest power draw, the public evidence may be enough to justify a site visit and proposal request. If the buyer is placing latency-sensitive financial systems, public-sector workloads, disaster-recovery infrastructure or high-density compute, the public evidence is not enough.

Those customers need a capacity letter, topology documents, failover evidence and contract language that ties service levels to the exact room, rack and network paths they will use.

The network evidence is live, but it is not broad

AS142379 is the routing anchor for the directory entity. APNIC RDAP for AS142379 names the autonomous system "ISC-DC-AS-ID" and gives the holder context as PT. INDONESIA SUPER CORRIDOR - DATA CENTER in Indonesia. Its administrative and technical contact data points to an ISC email address, while abuse contact data uses the ISC hostmaster address at a Cyber Building location. That is strong registry identity evidence.

The IP-resource picture shows a CNI group boundary. APNIC RDAP for 103.91.24.0 lists the 103.91.24.0 - 103.91.27.255 block as CNI-ID, allocated portable address space for PT Cyber Network Indonesia, an internet service provider in Jakarta. APNIC RDAP for 123.253.248.0 similarly lists 123.253.248.0 - 123.253.251.255 as CNI-ID. That does not weaken ISC's operating case, because ISC's public and third-party records repeatedly place it within a CNI Group context. It does mean customers should understand which legal and operational entity controls the address space, the facility, the exchange and the customer contract.

RIPEstat's AS overview reported AS142379 as announced on 12 July 2026 and named the holder as ISC-DC-AS-ID - PT. INDONESIA SUPER CORRIDOR - DATA CENTER. RIPEstat's announced-prefixes endpoint showed six current IPv4 /24s: 103.91.24.0/24, 103.91.25.0/24, 103.91.26.0/24, 103.91.27.0/24, 123.253.248.0/24 and 123.253.249.0/24. RIPEstat's routing-status data showed all 325 of 325 IPv4 RIS peers seeing the route set at the query time, 1,536 IPv4 addresses announced and no current IPv6 announcements visible to RIS.

That is good evidence of reachability, but it is not a complete diversity story. RIPEstat's ASN-neighbours data showed one observed neighbour: AS38496. APNIC RDAP for AS38496 identifies that AS as CNI-AS-ID for PT Cyber Network Indonesia. This looks like an internal or group-adjacent upstream/aggregation relationship rather than evidence that AS142379 has multiple independent external upstreams visible in global BGP. If a facility customer needs carrier diversity, the question is not "does ISC route addresses?" The question is "how many physical entrance paths, carrier cross-connects and upstream policies can my service actually use?"

Route security is a brighter point. RIPEstat's RPKI validation for 103.91.24.0/24 and RPKI validation for 123.253.248.0/24 both returned a valid status for AS142379 at the query time. RPKI validity does not prevent outages, and it does not prove facility diversity, but it is a real routing-hygiene signal. It reduces one class of origin-misstatement risk and shows that the CNI/ISC address environment is not an entirely neglected routing surface.

IPv6 is the weaker signal. Baxtel describes the ISC Tower as fully IPv4 and supported IPv6, and ISCX markets IPv4 and IPv6 peering. But RIPEstat's current AS142379 view showed no IPv6 prefixes visible at query time. That may mean IPv6 is provided through other ASNs, through exchange LANs, through customer networks or not currently originated by AS142379. For buyers, the practical point is simple: do not assume dual-stack service from marketing wording. Ask which ASN originates customer IPv6, whether the cloud packages include IPv6, whether RPKI covers it, and whether IPv6 paths have the same monitoring and support as IPv4.

ISCX is strategically useful, but it does not prove every customer path

ISC's exchange story is a real asset. The ISCX site describes "Connectivity Internet Exchange Point with Tier IV Data Center Support in Indonesia" and lists IXP Manager access, traffic status, MAC-address and IRR filter updates, monitoring dashboards, route-server support, looking glass, BGP communities, IRR filtering and RPKI. PeeringDB's ISCX page lists ISCX Internet Exchange under PT. Indonesia Super Corridor in Jakarta, with the website http://iscx.isc.id, technical contact fields and a June 2025 update timestamp. PeeringDB's PT. Indonesia Super Corridor organisation page gives the Cyber 1 address context and identifies the organisation behind the exchange-facing records.

For a data-centre operator, an exchange can matter as much as raw transit. It can reduce domestic latency, keep traffic local, attract content and access networks, and create a commercial reason for carriers to maintain presence in the building. ISC's pages repeatedly mention IIX, OIXP and Equinix IX in service bundles. Its cloud offers claim 1 Gbps access to IIX, OIXP and Equinix IX, while colocation pages package IIX and IX bandwidth into rack plans. Those claims fit a facility that sells not only space and power but proximity to Indonesian interconnection.

The caution is that exchange presence and customer redundancy are different things. A route server, IXP Manager and looking glass help members manage peering. They do not by themselves prove that a colocated customer has two fibre entrances, two meet-me rooms, two upstream contracts, isolated building pathways or tested failover from one carrier to another. An exchange can be a concentration point as well as a resilience tool. If many customers rely on the same switch fabric, power domain, meet-me room or upstream aggregation path, the exchange becomes part of the common failure domain.

PeeringDB also creates an interesting split. ISCX and the PT. Indonesia Super Corridor organisation are visible, and PeeringDB has a network page for AS136825, a related Indonesia Super Corridor profile with interconnection facilities including CNI/ISC DC CBR, CNI DC MPR and CNI DC DPS. But a direct PeeringDB API query for AS142379 returned no AS142379 network profile at check time. That absence is not a problem by itself; many facility operators separate facility, exchange and service ASNs. It does mean customers should ask which AS, which exchange fabric and which physical port their particular service uses.

The strongest buyer question is topological: "Draw the path." For a full rack at MPR, show utility to UPS to rack, cooling to rack, cross-connect to meet-me room, carrier to upstream, exchange port to route server, and backup network to DRC if applicable. For a cloud VM, show hypervisor, storage, top-of-rack switch, aggregation, firewall, transit, peering, backup and management portal. For a disaster-recovery customer, show the primary site, replication path, RPO/RTO measurement and restoration target. Without that drawing, ISCX is an attractive signal, but not a guarantee.

Ownership and operating boundary still need contract-level clarity

ISC's public evidence repeatedly overlaps with the CNI group environment. APNIC's IP allocations reviewed here are assigned to PT Cyber Network Indonesia. AS38496, the single observed AS142379 neighbour in RIPEstat's view, is CNI-AS-ID. PeeringDB profiles place PT. Indonesia Super Corridor, ISCX and CNI-branded facility names in the same practical interconnection landscape. Third-party facility directories describe ISC as part of the CNI Group context. This pattern is not suspicious. It is normal for data-centre, exchange and ISP businesses to share buildings, corporate parents, IP resources, operations teams and network assets.

But shared context changes diligence. A customer should not stop at the brand on the web page. It should identify the contracting entity, the facility operator, the IP-resource holder, the exchange operator, the remote-hands provider, the billing party and the party responsible for incident communications. If one company owns the building, another runs the exchange, another holds the address space and another signs the service order, the customer needs to know where liability and escalation sit.

The same question applies inside the facility: is a cloud service operated by ISC on ISC-owned equipment, by a CNI affiliate, by customer equipment in an ISC rack, or by a partner whose name is not visible on the public product page?

The answer matters during failures because outages do not respect marketing boundaries. A customer may have a colocation contract with one entity, an IP assignment from another, a cross-connect through the exchange team, a support ticket through a customer portal and a DRC replication path through a third service. If those functions are operationally integrated, the customer benefits from one coordinated recovery team. If they are administratively separated, recovery can slow while teams decide who owns the problem. The public record does not let an outside reader resolve that boundary.

For procurement, the cleanest evidence would be a service schedule that maps every dependency to an accountable party. It should say who controls the room, who maintains UPS and generators, who operates cooling, who manages customer cross-connects, who owns the cloud platform, who announces customer prefixes, who handles abuse, who approves emergency access and who speaks to customers during an incident. This is not legal trivia. In a power event, route leak, access-card failure or DRC activation, the boundary determines how quickly a real person can make a decision.

The disaster-recovery page asks the right questions and leaves the hard answers open

The Bali DRC page is useful because it explicitly names recovery concepts. It mentions RPO, RTO, universal restore, business application protection, compression, deduplication, multiple-exchange connectivity, resilient power, fire protection, monitoring and redundant precision air conditioning. That vocabulary is exactly what enterprise buyers should expect from a disaster-recovery provider. The page does not merely say "safe data"; it identifies recovery time, recovery point, network, power, fire and cooling as the components of the offer.

But recovery language becomes evidence only when it is tied to tests. A public DRC page cannot tell a bank, government agency, e-commerce operator or SaaS company whether its workload will restart inside the promised window. The answer depends on replication mode, storage consistency, application dependencies, DNS and routing cutover, identity systems, database write ordering, backup immutability, test frequency and customer staff access. "Gigabit connection to Multiple Exchange" is a useful claim, but it is not the same as measured replication bandwidth under load.

"Full backup generator capacity" is encouraging, but it is not the same as fuel runtime during a regional emergency.

The DRC page also raises a facility-separation question. Bali is physically distant from Jakarta, which can be valuable for regional disaster recovery. But distance increases latency, changes network dependency, and can complicate data-consistency designs. For some workloads, Bali may be excellent as backup or warm standby. For low-latency transactional systems, it may require careful asynchronous replication and acceptance of data-loss windows. Customers need to know whether ISC's DRC offer is backup-and-restore, pilot-light, warm standby, active-active or simply colocation in a second site.

Each pattern has a different cost and failure behaviour.

This matters because "DRC" can be oversold in the market. A second room with power and cooling is not enough. A disaster-recovery centre has to be exercised. A customer should ask for the last test date, test scope, achieved RPO and RTO, failure assumptions, runbook ownership, staffing plan, customer notification process and post-test evidence. It should ask whether restore capacity is reserved or best-effort. It should ask whether DRC network paths go through the same Jakarta concentration points that failed.

It should ask what happens when the disaster is not a building outage but a cyber incident, billing lockout, cloud-controller failure or accidental deletion.

ISC's public DRC material is strong enough to justify those questions, not strong enough to answer them. The company clearly markets the concepts that matter. It has a named Bali facility in Uptime's client listing and Datacenters.com/DatacenterMap-style directories. What is missing publicly is customer-grade recovery proof. That is not unusual in colocation, because many details sit in proposals and contracts. But it means public readers should not convert "RPO" and "RTO" headings into confidence without asking for measured evidence.

Who is affected if the platform fails

The affected parties are broader than rack tenants. A traditional colocation customer may lose access to hosted equipment if power, cooling, access control or smart-hands fails. A cloud customer may lose compute, storage, public IP service or management access if ISC-operated virtual infrastructure fails. An exchange entity may lose peering or local traffic-management visibility if ISCX or its supporting facility services fail. A DRC customer may discover that its recovery plan exists on paper but cannot be executed at the required speed if replication, routing, staffing or fuel logistics fail.

The same building can support several different risk profiles at once.

The most sensitive customers are those using ISC for Indonesian locality and continuity. Domestic enterprises, financial-sector suppliers, government-adjacent systems, media platforms, content networks and regional SaaS providers may care about Jakarta reachability, local exchange access, Indonesian support channels and data-location confidence. For them, the facility is not just a cheaper rack. It is part of the service boundary customers use to meet latency, compliance and continuity expectations.

The second affected group is smaller networks and content providers that might use ISCX or ISC-hosted infrastructure for peering. If a route server, switch fabric or facility power domain fails, local traffic may reroute to longer paths or fail for networks without backup peering. If an IXP portal or monitoring system fails, members may lose operational visibility even if packet forwarding continues. The public ISCX material advertises monitoring dashboards and route-server functions; customers should ask whether those systems are out-of-band, redundant and operated independently from the exchange fabric they monitor.

The third affected group is customers that buy cloud rather than space. Cloud buyers often have less visibility into where their workloads sit. They may see a VM plan, memory, storage, public IP and bandwidth package, but not the host cluster, storage replication, hypervisor maintenance policy, backup schedule or support escalation path. If ISC's cloud services are built on a compact resource pool, the practical risk is noisy-neighbour contention, host maintenance, storage failure, limited international bandwidth or slow support during a facility incident.

The public plans are useful for pricing and scope; they are not enough for production architecture.

The fourth affected group is resellers or managed-service providers who might place customer systems inside ISC without exposing ISC as the dependency. When a white-labelled or reseller-hosted service fails, the end user often sees only the immediate vendor. The underlying data-centre failure can be invisible until recovery stalls. For those chains, ISC's operating evidence matters even if the end customer never signs with ISC directly.

The failure paths to test are ordinary and unforgiving

The first failure path is utility power. ISC's pages mention dual-source power, separate distribution boards, resilient power from two voltage sources and generators. Those are the right components. Customers should still verify the single-line diagram, whether both sources are independent utility feeds or internal distribution paths, whether generator capacity supports full IT load and cooling together, how long fuel lasts at committed load, whether refuelling is contracted during a citywide event, and whether maintenance can be performed without moving customer loads into a reduced-redundancy state.

The second failure path is cooling. ISC's DRC page mentions precision air conditioning with a redundant system and its maintenance pages refer to cooling-system work. That is a good start. The risk is that cooling and power constraints interact. A rack may be sold with 10A, but dense equipment can create hot spots, and cooling redundancy has to support actual load, not average load. Customers should ask for cold-aisle/hot-aisle containment details, temperature and humidity ranges, cooling unit redundancy, chiller or DX design, maintenance history and alarms visible through DCIM.

The third failure path is carrier meet-me interruption. ISC's public material markets cross-connects, IIX/IX bandwidth, ISCX, route servers, OIXP, Equinix IX and multiple-exchange language. The BGP view for AS142379 still shows one observed neighbor, AS38496, and no current IPv6 route from that AS. That does not contradict the exchange story, but it means the public AS-level evidence does not show broad transit diversity. Customers should require a carrier list, path diversity statement, meet-me-room design, cross-connect SLA and proof that failover has been tested from the customer's rack or virtual network.

The fourth failure path is facility fire, flood or access interruption. The Bali page mentions FM200 and smoke sensors above and below raised floor, CCTV and card/fingerprint rack access. The home page mentions manned security and motion detectors. Those are physical controls, but customers should ask about water ingress, roof and drainage risk, floor loading, fire-zone separation, emergency access, customer access during incidents and whether insurance or building-management constraints could delay repairs. A data centre can have good controls and still be exposed to ordinary building dependencies.

The fifth failure path is construction or capacity mismatch. The public record carries multiple capacity numbers: ISC's 5 MW MPR headline, Baxtel's 6 MW company marker, Datacenters.com's 16.0 MW figure for MPR, and other market references to up to 8 MW IT load. The existence of different numbers is not itself alarming, but it is a warning against buying from a slide number. Customers should ask which number is current, whether it is utility, gross, critical, IT or planned capacity, and whether their contract reserves capacity or merely gives them access to capacity while available.

The sixth failure path is administrative. DCIM accounts, customer portals, support desks, billing systems and access permissions are part of infrastructure. If a portal is down, a customer may not be able to monitor traffic, open a ticket, provision cloud capacity, adjust network filters or verify that a maintenance event is planned. ISCX advertises IXP Manager and monitoring dashboards. ISC advertises customer DCIM accounts. Buyers should treat those systems as operational dependencies and ask how they are backed up, monitored and supported.

What would change the grade

ISC can improve the public risk grade without publishing sensitive customer data. A short network page would help: ASNs used for facility, cloud and exchange services; current IPv4 and IPv6 prefixes; upstream/transit providers; exchange fabrics; route-server policy; RPKI status; looking-glass links; PeeringDB records; abuse and NOC contacts; and maintenance-notification channels. The company already has enough public material to support such a page. Consolidating it would reduce ambiguity.

A facility-capacity page would help more. It should distinguish CBR, MPR and Bali DRC; list design tier and award scope; state gross power, committed IT load and available sellable load; explain rack density bands; identify utility-feed and generator assumptions; disclose cooling redundancy; and explain whether cloud services run in one or more sites. It does not need to expose individual customers. It needs to make marketed capacity testable.

A recovery-evidence page would be even more valuable. It could describe the disaster-recovery patterns available, publish sample RPO/RTO categories, explain restore-test frequency, list backup and replication options, state whether DRC capacity is reserved or best-effort, and provide a status or incident-history channel. Customers do not need perfection. They need to know whether the company has practised the failure it sells protection against.

For network confidence, AS142379 should show broader public diversity if it is meant to serve production customers directly. Multiple visible upstreams, an AS142379 PeeringDB network profile, current customer-usable IPv6, clean RPKI coverage across all visible prefixes and a public looking glass would all raise confidence. If AS142379 is merely an internal or facility-specific ASN while customer diversity sits under AS136825, AS38496 or other CNI/ISC ASNs, ISC should say that plainly. Ambiguity forces customers to guess which public route evidence applies to their service.

For procurement confidence, ISC should align market capacity claims. A buyer seeing 5 MW, 6 MW, 8 MW and 16 MW in different public places cannot know which figure controls. The answer may be simple: site power, IT load, planned expansion, building capacity or a directory error. But the public mismatch creates friction. In data-centre purchasing, a clean capacity statement is not cosmetic; it determines whether a customer can reserve space and power for three to five years.

Operating grade

PT. INDONESIA SUPER CORRIDOR - DATA CENTER earns a medium network-and-operating evidence grade with a strong facility-existence component. The strong part is deserved: ISC has official facility pages, named CBR/MPR/Bali assets, Uptime Institute issued-award records, public rack and cloud offers, an ISCX exchange surface, APNIC AS identity, current RIPEstat IPv4 visibility and valid RPKI on sampled visible prefixes. This is far better than a dormant shell or unverified hosting brand.

The downgrade is also deserved. Public evidence does not yet prove usable capacity at the advertised scale. It does not reconcile competing power figures. It does not show current IPv6 for AS142379. It shows one observed BGP neighbor for that AS. It does not publish carrier lists, utility one-lines, fuel runtime, cooling test evidence, customer restore results, status history, incident communications, cloud architecture or site-specific failover rules. The company markets the right ingredients, but customers still have to verify the recipe.

The practical conclusion is not to avoid ISC. It is to buy carefully. For modest colocation, exchange-adjacent presence, Indonesian locality or a Jakarta/Bali recovery conversation, ISC belongs on the diligence list. For production workloads that depend on uninterrupted power, diverse carrier paths and proven recovery, buyers should demand site tours, engineering documents, live route tests, failover drills and contract language that maps the marketed service to a specific facility and dependency path. In data centres, the difference between "available racks" and "survivable capacity" is where the real risk lives.