Trust · Standard

How we decide what we are allowed to claim.

Every security claim we publish carries an evidence status, and separately identifies who owns the control. A planned control is never presented as a control already running.

Our security principles

Seven rules, applied to every product
01

Least privilege

An application requests only the permissions its documented functionality needs, and those permissions are checked against the production manifest before release.

02

Data minimisation

Our products process only the customer data their documented functionality requires. Where an integration can work with a narrower dataset, permission set or data flow, we take the narrower boundary. Least privilege governs what an application can reach; data minimisation governs what it actually processes once it has access.

03

Explicit integration boundaries

Where a product talks to an external service, that integration is identifiable from the production application configuration.

04

No hidden infrastructure

Where LT.Solutions operated infrastructure takes part in processing customer data, we document that boundary. We do not describe an externally hosted component as platform native because its interface happens to run inside Atlassian or Google.

05

Credentials and access tokens

Credentials and access tokens are handled separately from the business data our applications process. They are stored using security controls appropriate to the product’s hosting architecture, and are never treated as ordinary application data.

06

Safe synchronisation

An integration has to tell the difference between a source that is unavailable and a source that is intentionally empty. Where it applies, a failed or incomplete read stops the sync rather than being read as an instruction to delete customer data.

07

Platform controls

Some controls come from Atlassian, Google or another hosting platform rather than from us. Where a control is inherited, we say so rather than presenting it as an LT.Solutions implementation.

Documentation standard

Evidence status, in order of maturity

ProposedA documented design, not represented as an operating security control.
ImplementedConfirmed in the application code or configuration, and not yet independently confirmed against the deployed production environment.
VerifiedConfirmed against the deployed production environment.
InheritedSupplied by the underlying platform rather than implemented by LT.Solutions, so we do not claim a platform capability as our own. An inherited control can also be verified, and the two labels are not alternatives.
When an architecture changes

Product architectures change. A new connector, a new hosting model or a new processing service can move the security boundary of an application. A material change to authentication, storage, external connectivity, customer data processing or hosting triggers a review of this Security Centre before or alongside the matching production release.

Products in development

We sometimes publish information about a product before it is generally available. A product appearing on this website does not mean its production security architecture is final. Detailed security claims are published against the production verified architecture.

We use analytics cookies to understand how the site is used, only if you accept. Read our privacy policy.