Security Policy

This policy describes the security standards INX applies to its own infrastructure and operations, and the baseline security practices applied in client delivery work. It is not a compliance declaration and does not assert conformity with any external certification framework.

Security practices applied within client-specific systems are governed by the engagement specification and the security requirements documented in the relevant Statement of Work. Where a client has specific compliance obligations (e.g., ISO 27001, SOC 2, PCI-DSS), these are addressed as part of the engagement scope.

Credentials, API keys, and secrets are managed through dedicated secrets management tooling - not stored in source code, configuration files committed to version control, or shared via email or chat. This is a non-negotiable operational standard, not a best-effort guideline.

Production credentials are scoped to the minimum permissions required. Service accounts and API keys are not shared across environments. Credential rotation is performed when access is revoked or suspected to be compromised.

Clients are advised to rotate any credentials shared with INX during an engagement once delivery is complete and access handover is confirmed. INX's internal credential management standards are applied to all client access provided during delivery.

Access to client systems and repositories is restricted to INX team members who require it for the specific engagement. Access is not granted broadly or speculatively. When an engagement concludes, INX team members' access to client systems is removed and confirmed in the handover documentation.

INX does not retain standing access to production systems beyond the engagement period. Any access required for post-delivery support is explicitly agreed in writing and time-bounded.

Multi-factor authentication is required for all INX team member access to cloud platforms, code repositories, and third-party tooling used in client delivery.

Confidential information shared by clients during an engagement - business logic, user data, operational data used for testing - is handled under the confidentiality obligations described in the engagement agreement and on this site's Confidentiality page.

Production data is not used in development or test environments without explicit written consent. Where sanitised or synthetic test data can serve the same purpose, that is the default approach.

Client data is not retained beyond the period required for delivery unless specifically agreed. Upon engagement conclusion, INX confirms in writing what data was held and how it was disposed of.

INX evaluates third-party services before incorporating them into client systems, with particular attention to: data handling and jurisdiction, security posture and public disclosure history, and whether the service is appropriate given the sensitivity of the data involved.

INX does not introduce tooling with unclear data handling practices into production systems handling sensitive client or end-user data. AI-assisted development tools are not provided access to production client credentials or confidential production data.

In the event of a security incident affecting INX infrastructure or a client system under active INX engagement, INX will notify the relevant client as soon as the scope and nature of the incident is understood - and in any case within 48 hours of identification.

Security-related concerns about INX's own systems, or about systems INX has delivered, should be reported to info@ideanestx.com. INX will acknowledge the report within two business days and communicate an assessment and response timeline.