IID CloudIID Cloud
/
← Back to home Chapter C — Security

Security

Keamanan

Effective from · 2026-08-24 PT. Indonesia SCM Industrial

This document is a draft and must be reviewed by legal counsel before publication.

1. Scope

This page describes the security controls we apply to the IID Cloud GPU platform and to this website. It is written for the technical and procurement teams who evaluate us.

Capitalized terms used on this page — Order, Node, Term — have the meanings given in our Terms of Service.

It is informational and does not itself create obligations. Binding commitments — including any availability target, control commitment or audit right — are those recorded in your Order or in a separate agreement. Where a control depends on how a particular deployment is configured, the Order is the authoritative record.

2. Shared responsibility

Security of a rented GPU Node is divided. The line sits at the boundary of the guest environment.

We are responsible forYou are responsible for
Physical facilities and their access controlThe guest operating system and its patching
Power, cooling and environmental controlsSoftware, libraries and container images you install
Network fabric, segmentation and edge protectionNetwork access rules you configure inside your environment
Host firmware, hypervisor and isolation layersCredentials, SSH keys and secrets you hold
The control plane, its authentication and its audit trailUser lifecycle inside your own organization
Capacity allocation and tenant separationThe data, models and code you bring in
Deletion of Node storage after an Order endsBackups and retrieval of your data before it ends

3. Physical and environmental security

Our Nodes run in commercial data-center facilities in Indonesia, Malaysia and Thailand, operated with partners. We require of those facilities:

  • controlled entry with identity verification and logged access, and escorting of visitors;
  • continuous video surveillance of entry points and equipment areas;
  • segregation of our equipment from other tenants’ equipment;
  • redundant power with generator backup, and redundant cooling;
  • fire detection and suppression appropriate to a data hall;
  • documented procedures for equipment intake, movement and disposal.

We do not permit customer personnel to enter the facilities. Hardware is not shipped in or out at a customer’s direction.

4. Network security

  • Tenant traffic is segregated at the network layer; a tenant cannot reach another tenant’s internal network.
  • Management interfaces are separated from tenant data paths and are not exposed to the public internet without authentication.
  • The public edge is filtered, and volumetric attack traffic is absorbed or dropped upstream of the platform.
  • Only the ports and protocols needed for the service are reachable by default; you open what you need inside your own environment.
  • High-bandwidth interconnect between GPUs within a multi-GPU node — NVLink and InfiniBand fabric — is dedicated to that Node and is not shared across tenants.
  • Where an Order includes private interconnect or a dedicated egress path, its configuration is recorded in the Order.

5. Tenant isolation

  • We support both soft tenancy and hard tenancy, chosen according to the workload and recorded in the Order.
  • Under hard tenancy, accelerator resources are not shared across tenants: a GPU is allocated to one tenant at a time.
  • Isolation is enforced at GPU and node level, with network segregation between tenants.
  • NVIDIA 8x H100 SXM nodes are allocated to a single tenant as one indivisible unit — the eight GPUs and their fabric are never split between customers.
  • GPU memory and local storage are cleared before a Node is re-allocated to another tenant.

6. Host hardening

  • Host operating systems are built from a controlled image with unnecessary services removed.
  • Firmware, BMC and GPU driver versions are tracked and updated on a managed schedule.
  • Management planes are reachable only from our administrative network.
  • Hosts are monitored for unexpected process, configuration and integrity changes.

7. Identity and access management

For your own users of the control plane:

  • SSO for integration with your corporate identity provider;
  • Two-factor authentication;
  • Role-based access control across teams and projects, with policy-based access for every workload and interface;
  • separate permission sets for the CLI and the API, so automation can be granted narrower rights than a person;
  • quota management per team and per project, so one team cannot consume another’s allocation.

8. Our own administrative access

  • Internal access follows least privilege and is granted by role, not by individual request.
  • Administrative access requires multi-factor authentication.
  • Access is reviewed periodically and revoked promptly when a person changes role or leaves.
  • Administrative actions are logged; the logs are retained and reviewable.
  • We do not access the contents of your workloads, models or datasets except (a) at your request for support, (b) where strictly necessary to contain a genuine security incident, or (c) where required by law — see Privacy Policy section 10.

9. Encryption

  • Traffic to this website and to management interfaces is encrypted with TLS; obsolete protocol versions and cipher suites are disabled.
  • Encryption of node storage at rest depends on the configuration agreed in the Order. Raise the requirement before provisioning so it can be recorded.
  • You control any application-level or filesystem-level encryption inside your environment, and you hold those keys. We cannot recover data you have encrypted with a key we do not hold.
  • Secrets used by our own automation are held in a managed secret store, not in source code or images.

10. Logging, monitoring and audit trail

  • Authentication events, administrative actions, resource allocation and quota changes are logged.
  • Audit logs are exportable, so you can retain them in your own SIEM for as long as your policy requires.
  • Resource usage is tracked and is the basis of what appears on your invoice.
  • Platform telemetry is monitored for anomalies; alerts route to an on-call engineer.
  • Our retention periods for security and administrative logs are stated in the Privacy Policy.

11. Vulnerability and patch management

  • We monitor vendor advisories for the hardware, firmware, hypervisor and platform components we operate.
  • Severity is assessed against exploitability and exposure, and remediation is prioritized accordingly; critical issues on internet-facing components are treated as urgent.
  • Patching of components we operate is scheduled as maintenance under our Terms of Service, section 18. Emergency patching may be applied without prior notice where the platform is at risk.
  • Patching inside your guest environment is yours. We do not patch your operating system or your software.

12. Change management

  • Changes to production are reviewed before release and are recorded so they can be traced and reversed.
  • Changes that may affect tenants are scheduled and, where practicable, announced in advance.
  • High-risk changes have a documented rollback path.

13. Personnel security

  • Staff and contractors with access to the platform are bound by written confidentiality obligations.
  • Pre-engagement checks are carried out to the extent permitted by Indonesian employment law.
  • Staff receive security awareness briefing on joining and periodically thereafter.
  • Access is provisioned on joining, adjusted on role change, and removed on departure.

14. Suppliers and subprocessors

  • We use data-center partners, a hosting and content-delivery provider, and standard business systems. We assess a supplier’s security posture before we rely on it for anything that touches customer data or customer workloads.
  • Suppliers that process personal data on our behalf are bound by written agreements limiting them to our instructions and requiring equivalent protection.
  • We will provide the current list of subprocessors on request — see section 20.

15. Resilience, backups and capacity

  • Facility-level resilience — redundant power, cooling and network paths — is provided by the data-center and network layers described above.
  • We do not back up your Node storage unless the Order says we do. Node storage is working storage. Keep your own copies and retrieve your data before an Order ends, as set out in the Terms of Service, section 20.
  • We keep our own configuration and control-plane state backed up so that the platform can be recovered.
  • Capacity is planned so that a reserved Order can be honoured for its Term; if we cannot honour it, section 15 of the Terms applies.

16. Incident response and notification

  • Suspected incidents are triaged by an on-call engineer, with escalation to management for anything affecting tenant isolation, availability or data.
  • We contain first, then investigate, then remediate, and we record what happened.
  • Where an incident affects you, we will notify your administrative contact with what we know, what we are doing, and what we recommend you do — and we will follow up when the investigation closes.
  • Where a personal data breach is notifiable, we notify the affected parties and the competent authority within the period required by the Personal Data Protection Law.
  • If you believe you are experiencing a security incident on your Nodes, tell us immediately at the address in section 19 and mark it urgent.

17. Data deletion and media handling

  • When an Order ends, Node storage is cleared before the capacity is re-provisioned to anyone else, and GPU memory is reset.
  • Where practicable we keep Node storage intact for a short retrieval window after expiry — see Terms section 20 — after which the data is deleted.
  • On written request made before expiry, we will confirm deletion once it is complete.
  • Failed or decommissioned storage media are sanitized or destroyed before leaving a facility, and disposal is recorded.

18. Security of this website

iidevcloud.com is a static site. It sets no cookies, loads no third-party analytics, carries no advertising or social pixels, has no chat widget, and posts no form data to any server. Quote requests are composed in your own email client and sent by you. The only value stored in your browser is your language preference. There is therefore no login, no session and no user database attached to this website.

19. Reporting a vulnerability

If you find a vulnerability in our platform, our control plane or this website, please report it privately to kei_hu@iidevcloud.com with the subject line “Security report” before disclosing it publicly.

Please include: what you found, where, the steps to reproduce it, the impact you believe it has, and how we can contact you. We will acknowledge your report, keep you informed while we investigate, and tell you when it is resolved.

We ask that you:

  • give us a reasonable period to remediate before publishing;
  • do not access, modify or delete data that is not yours;
  • do not degrade the service for other tenants, and do not run denial-of-service tests;
  • do not use social engineering or physical intrusion.

Do not run penetration tests against the platform without our written consent — that is prohibited by Terms of Service section 16. We do not currently operate a paid bug bounty; we will credit researchers who ask to be credited.

20. Security questionnaires and assurance requests

For vendor security reviews, questionnaires, a subprocessor list, or a discussion of controls for a specific deployment, write to kei_hu@iidevcloud.com. Please tell us the deadline you are working to. Where a request involves non-public detail we will ask for a mutual non-disclosure agreement first.

21. What we ask of you

Most incidents in rented infrastructure begin inside the guest environment. The measures that matter most:

  • patch the guest OS and your dependencies, including GPU drivers and container base images;
  • use key-based authentication, disable password login, and rotate keys;
  • never embed long-lived credentials in an image, a notebook or a repository;
  • expose only the ports you need, and restrict them by source address;
  • use separate credentials for automation and give them the narrowest role that works;
  • remove access the day someone leaves;
  • export your audit logs into your own monitoring, rather than relying on ours;
  • keep your own backups, and test that you can restore from them.
Privacy Policy · Terms of Service · Refunds · ← Back to home