Security

Security that holds up in environments we don't operate

Most of our products don't run on our infrastructure. They run in your data centers, on your networks, and in environments that are often isolated from the public internet entirely.

That shapes everything about how we approach security. We can't patch around a problem after the fact, and we can't rely on controls we operate on your behalf. Security has to be built into the release itself, verified by assessors outside i2, and documented well enough that your teams can deploy and maintain it to your own standards in your environment, under your control.

Where we do host a service, the same discipline applies, backed by operational controls within our ISO 27001 scope.

Where our security effort goes

Six disciplines, applied continuously and independently assessed each year.

Secure development lifecycle

Threat modelling at design, secure coding standards, automated security testing in every pipeline run and mandatory peer review before anything reaches a release.

Independent penetration testing

Annual testing of our products by a CREST-accredited provider, with findings tracked to closure and a summary report published for customers.

Finding and fixing vulnerabilities

Continuous scanning and dependency monitoring, with remediation targets tied to severity and security advisories issued directly to affected customers.

Supply chain assurance

Every third-party component tracked, licence-reviewed and monitored for vulnerabilities, with a Software Bill of Materials published per release.

Securing our own environments

Hardened corporate and build environments with multi-factor authentication, endpoint detection, centralised monitoring and defined patching timescales.

Built for modern environments

Current TLS and cipher suite support, integration with your identity provider, and hardening guidance that keeps our products aligned with the controls you already run.

Security practices in detail

A plain-English summary of the controls behind our certifications. Full policy documents are available through our Risk Ledger profile.

Secure development lifecycle

Threat modelling and architectural security review at design stage for material changes.
Static analysis, software composition analysis and secret detection on every pipeline run; builds fail on critical findings.
Mandatory peer review, with no direct commits to protected branches.
Build environments segmented from general corporate systems, with full change traceability from commit to release artefact.
Release artefacts digitally signed, with published checksums so you can verify what you install.

Independent testing and assurance

Annual penetration testing of our products by a CREST-accredited provider, against a representative deployment.
Red team exercises against our corporate estate and build pipeline, scoped around the threat actors most likely to target a supplier in our sector.
Automated control validation between audits, so configuration drift is caught in days rather than at the next annual assessment.
Annual assessment of our management systems by accredited third-party auditors.

Vulnerability management

Continuous vulnerability scanning across our products, dependencies and corporate infrastructure.
Dependency and threat intelligence monitoring, so newly disclosed component vulnerabilities are assessed against our codebase quickly.
Remediation targets tied to severity: critical within seven days, high within 30, medium and low in the next scheduled release.
Security advisories issued directly to customers with severity, affected versions and remediation guidance.
Reports from security researchers and customers triaged through the same process.

Security support lifecycle

Security fixes are delivered in supported product releases. The supported versions for each product are published in our documentation and kept current there.
End-of-support dates are published ahead of time, so upgrade planning can start before fixes stop.
Once a version reaches end of support it no longer receives security fixes. We'll advise on the upgrade path, but continuing to run an unsupported version means running without them.
Fixes are packaged so they can be applied in air-gapped and tightly change-controlled deployments.

Securing our own environments

Multi-factor authentication across corporate systems, with phishing-resistant factors for privileged and development roles.
Endpoint detection and response deployed across the estate, with centralised logging and alerting.
Defined patching and vulnerability management timescales for corporate infrastructure and developer workstations.
Least privilege by default, a joiners/movers/leavers process and quarterly access recertification.
Source control, build systems and support records protected to the same standard as the products they produce.

Keeping products fit for modern environments

Traffic between product components protected with TLS 1.2 or above, using modern cipher suites, with legacy protocols disabled by default.
Certificates issued and managed within your own PKI, so the trust chain stays under your control.
Connections to external data sources and connectors configured to enforce transport encryption.
Integration with your existing identity provider through Active Directory, LDAP, SAML 2.0 or OIDC, with role-based access control and audit logging you can forward to your SIEM.
Designed to operate normally on encrypted storage, and to support FIPS-validated cryptography where your deployment requires it.
Hardening guidance published for each product, and cryptographic standards reviewed as they evolve.

Personnel security

Background screening for all staff, with enhanced national vetting where customer contracts require it.
Confidentiality obligations in every employment and contractor agreement.
Annual security awareness training plus role-specific secure development modules.
Simulated phishing programme with follow-up coaching rather than punitive measures.

Security incident response

Monitoring and alerting across our corporate and build environments, with a defined escalation path and named incident lead.
A documented incident response plan, exercised at least annually.
Notification to affected customers without undue delay, to the timelines set out in your agreement.
Post-incident review for every material incident, with findings fed back into our controls.

Reporting a vulnerability

Raise a Support Case

If you've found a security issue in an i2 product, we want to hear about it.

From there it's triaged against the same severity model we apply to our own findings - a vulnerability reported from outside i2 moves through exactly the process one found by our engineers does.

Need more detailed assurance?

Procurement and assurance teams can access our full security documentation on Risk Ledger, including our SOC 2 report, ISO certificates and policies. If your review needs something we haven't published there, raise a support case and we'll confirm what we can provide.

Access our Risk Ledger profile

Raise a Support Case