Security and data protection

No responsible technology provider should promise that a system can never be compromised. A robust security architecture instead assumes that individual controls can fail and aims to prevent one failure from becoming a much larger incident.

A common approach to protecting sensitive data is to secure a database, restrict access to it and encrypt its contents. These controls matter, but they do not, by themselves, answer a critical question: if an attacker gained access to one part of the platform, how much information could they obtain - and what could they do with it?

For Step, this is a fundamental design consideration. We aim to reduce the amount of sensitive information held together, separate information that would be particularly damaging if combined, and introduce additional layers of protection around access to that information.

One of the central principles of our architecture is to separate identifying information from the wider information recorded about a person. A typical case-management record might combine a person's name, contact details, address, circumstances, support needs, referrals and case notes in a single record or closely connected database.

That creates an obvious concentration of risk: a compromise of that data store could expose both the person's identity and highly sensitive details about their life.

Step takes a different architectural approach. The identity layer holds identifying information, such as names, contact details and addresses, and provides the controlled mechanisms needed to resolve a person's identity. The platform data layer holds the wider case and support information, including information about needs, circumstances, interactions and referrals, without routinely storing the direct identifiers needed to identify the person.

The two layers are separated, and access to the information needed to connect them is controlled. The benefit is this: the information needed to identify someone is not simply sitting alongside all their sensitive case information in one place. Most importantly, if one data store is compromised, this separation can significantly reduce what an attacker can learn from that store alone.

Encryption is an essential part of protecting any system, but the way it is implemented matters. Our architecture supports organisation-level separation of encryption protections. This can reduce the potential impact of a compromised key: access to one organisation's encryption key should not, by itself, provide access to the information protected by other organisations' keys.

For enterprise customers, we also support a bring-your-own-key approach. Under this model, a customer can retain control of its own encryption key and grant Step controlled access when required, rather than relying entirely on Step to steward that key.

Sensitive information often needs to move between organisations. A person may have a support passport, a case record, or a referral involving another charity or service provider.

These connections are necessary for coordinated support, but they also create security challenges. A system must connect the right records without unnecessarily exposing identity information or undermining the separation between organisations.

Step is designed to support controlled connections between records and organisations without relying on a single, openly accessible identifier that joins everything together.

Where records need to be linked, the connection mechanism and the underlying data access are treated as separate security concerns. Controlled tokens and protected linkages can support the connection, while access permissions and revocation mechanisms govern whether that connection remains usable.

This is important for maintaining separation between organisations, supporting changes in access over time, and avoiding unnecessary disclosure when information is shared for a specific purpose.

A secure platform must protect not only its data stores, but also the accounts and applications through which people access information.

Step supports modern authentication mechanisms, including single sign-on (SSO) and multi-factor authentication (MFA), alongside controls intended to reduce the risk of unauthorised account access.

SSO allows organisations to use established identity providers and their associated authentication policies. Where configured, this can make it easier to apply consistent organisational controls without requiring staff to maintain another independent password.

MFA provides an additional layer of protection beyond a password. Account protections, logging, and monitoring of suspicious activity can help identify and respond to attempts to gain unauthorised access.

We treat identity verification, access authorisation and the separation of customer information as distinct but complementary controls.

Security includes the ability to detect problems, investigate incidents and recover from failures - not just prevent them.

Our approach includes security logging and monitoring, alongside protections against common account attacks. Backups provide an additional recovery mechanism if information is lost or damaged.

Backups are performed incrementally and stored in another physical location, helping to reduce the risk that a single infrastructure failure affects both the live platform and its recovery data.