Information Security Policy

Nimbit is a small, owner-operated cloud infrastructure provider. The people running the business also operate the infrastructure and are responsible for security. This policy sets out the basic requirements for protecting company and customer information and keeping the systems we manage secure and available.

We choose safeguards based on the sensitivity of the information, the systems involved, the risks we can reasonably identify, and our commitments to customers. This policy describes our security requirements; it is not a certification or a guarantee that incidents will never occur.

This policy applies to Nimbit’s operators and any contractors with access to company or customer information. It covers the infrastructure, devices, repositories, development environments, and third-party services we use to deliver and support our services.

Nimbit management owns this policy and makes security decisions. Everyone with access to Nimbit systems must follow it and promptly raise suspected security issues with management.

Our responsibility covers the systems and controls we administer. Customers and service providers are responsible for the parts they control. For each service, the applicable agreement or service documentation should make those boundaries clear, including responsibility for operating systems, applications, access, and backups.

We classify information as Public (approved for public sharing), Internal (routine business information not intended for public sharing), or Confidential (customer information, personal information, credentials, and sensitive business or technical information). Customer information is Confidential unless the customer has made it public or authorized its disclosure.

Public information may be shared openly. Internal information is limited to people who need it for company work. Confidential information requires authorized access and safeguards appropriate to its sensitivity. When the classification is unclear, treat the information as Confidential until management confirms otherwise.

We access and use customer information only as needed to provide the agreed service, carry out authorized support, meet contractual obligations, or comply with applicable law. We do not use it for unrelated purposes.

Confidential information must be accessible only to people with a legitimate business need. It must be encrypted when sent over untrusted networks. Encryption at rest is used where appropriate and supported by the system; responsibility for workload and disk encryption depends on the service.

We keep information only as long as reasonably needed for service delivery, operations, or contractual and legal requirements. When it is no longer needed, it must be securely deleted or returned as appropriate. Any agreed retention or deletion requirements also apply to copies and backups we control.

Before reassigning, returning, or disposing of storage media under our control, we must remove customer and company data using a suitable secure erase, cryptographic erase, or physical destruction method. If media cannot be sanitized, it must not be reused or released with readable data on it.

Access is limited to what each person needs to do their work. Administrative access is restricted to authorized operators, with multi-factor authentication required for administrative and security-sensitive services where supported.

We use individual accounts where supported. Passwords, private keys, API tokens, and other secrets must be kept in protected storage and shared only through a secure mechanism when operationally necessary.

Access must be updated when responsibilities change and removed promptly when no longer needed. Suspected exposure of a credential must be reported promptly so it can be revoked or rotated.

Access to a customer environment is limited to authorized service and support work. Having infrastructure access does not authorize browsing customer files or workloads.

For systems we manage, we use safeguards appropriate to their role: restricted administrative interfaces, network access controls, secure configuration, and workload isolation where applicable. Unneeded services and privileges should be disabled or restricted.

We review relevant security notices and vulnerabilities as part of maintenance. We prioritize fixes based on severity, internet exposure, and likely customer impact. Urgent risks may require an immediate change or temporary restriction; other updates can be scheduled around service availability.

We use available system logs and operational alerts to troubleshoot failures and investigate suspected security issues. Logging and monitoring vary by system; this policy does not promise continuous human monitoring or a staffed security operations centre. Logs containing Confidential information must have restricted access.

Source code and infrastructure configuration must be kept in access-controlled repositories. Secrets must be kept out of source code and public repositories and supplied through protected configuration or secret storage.

Before a material production change, the operator making it must consider the security and service impact, carry out testing appropriate to the risk, and identify a way to recover if it fails. Changes require management authorization; in our small team, the person authorizing and implementing a change may be the same person. A second-person review is used where practical for higher-risk changes.

Emergency fixes may need to happen before normal review or testing is complete. Significant emergency changes should be documented and reviewed afterward.

Development work should be separated from production where practical. We consider dependency security during development and maintenance and address relevant vulnerabilities according to their risk.

Nimbit’s operators approve software and hardware before introducing them into company infrastructure.

Open-source software must come from trusted sources. Before adoption, we consider its license, maintenance status, known security issues, and required access to systems or data.

Hardware must be suitable for its intended use and checked and securely configured before deployment. Previously used storage must be sanitized before reuse.

If we introduce an external service that handles Confidential information or has administrative access, management must first review its security safeguards, data handling, and access requirements.

This is our basic response plan for suspected unauthorized access, exposed credentials or data, malicious activity, and other events that may compromise information or systems. Customers should report concerns through their usual Nimbit support contact.

1. Report and take ownership. The operator who discovers or receives the report promptly alerts the other operator using the available internal contact channel. One operator takes the response lead; the other assists when available. If only one is available, that operator begins the response and seeks provider or specialist help when needed. Management owns customer communications and decisions about outside assistance.

2. Assess and record. Start a restricted incident note with the discovery time, known facts, affected systems or customers, and actions taken. Determine whether the event is ongoing and whether it involves data exposure, privileged access, or service disruption. Active compromise and likely exposure of Confidential information take priority over routine maintenance.

3. Contain and preserve evidence. Take proportionate steps to limit harm, such as revoking credentials, restricting access, or isolating affected systems. Preserve relevant logs and record changes where practical without delaying urgent containment. Do not copy sensitive evidence into public issues or unapproved tools.

4. Investigate and recover. Identify the likely entry point and scope, remove unauthorized access, and fix or mitigate the cause. Restore or rebuild affected services as needed. Before returning a system to normal use, check that the relevant access controls and service functions work and look for signs of continuing compromise.

5. Communicate. When an incident materially affects customer information or systems, management will notify affected customers in accordance with applicable contractual and legal requirements, seeking advice when needed. Communications should explain the known impact, actions taken, any steps customers should take, and when to expect an update. Distinguish confirmed facts from matters still under investigation.

6. Close and improve. After a significant incident, record the outcome, review what happened, and assign practical follow-up actions to an operator. Keep incident records access-restricted and retain them according to business, contractual, and legal needs. Review this plan at least annually, including whether operator and relevant provider contact details remain available and current.

We consider failure and recovery when operating the infrastructure we manage. Backup, redundancy, and recovery arrangements depend on the service and the responsibilities agreed with the customer.

Customers should not assume that a server or GPU service includes backups of their data, applications, or workloads. Backup ownership, retention, and recovery expectations must be established in the applicable service agreement or documentation.

Where Nimbit is responsible for backups or recovery, we maintain the relevant arrangements and check recovery capabilities at a frequency appropriate to the system and risk. Any availability or recovery commitments are those set out in the applicable service agreement.

Operators and contractors must use Nimbit and customer systems only for authorized work. They must not bypass security controls, improperly share credentials, disclose Confidential information without authorization, introduce malicious software, or use these systems for unlawful activity.

Devices used to administer systems or access Confidential information must have authentication, automatic screen locking, supported software, and security updates. Device encryption must be enabled where supported and appropriate.

Lost, stolen, or potentially compromised devices or credentials must be reported promptly. Confidentiality obligations continue after access ends where applicable.

Our use of AI tools must respect our confidentiality, security, intellectual-property, privacy, and contractual obligations.

Confidential customer information, personal information, credentials, and proprietary source code must not be submitted to third-party AI services unless the use is authorized and suitable safeguards are in place. This includes considering the provider’s data retention and training settings.

AI-generated code and configuration must receive human review and testing appropriate to the risk before production use. Nimbit will not use customer information to train AI models without the customer’s express authorization.

We consider applicable legal, privacy, contractual, and customer security requirements when operating our services.

An exception to this policy must have a business or technical reason and management approval. We document the exception and use alternative safeguards where needed to manage the risk.

Nimbit management is responsible for adopting and maintaining this policy. We review it at least annually and after material changes to our services, infrastructure, risks, or contractual obligations.