Governance17 September 20264 min read

Shared platform, separated customer data

A shared services provider needs one platform for every customer, while each customer wants to see only its own servers, incidents and costs. Here is how to have both without compromising security.

Running shared IT services means living with a built-in tension. Internally, you need to see everything at once: every server, every incident, every change and every cost across all your customers. That is the only way to plan capacity, coordinate outages and run operations as a whole. Your customers rightly expect the opposite. They want to see their own data and nothing else. They do not want anyone else looking at their application list or their monthly costs.

When this tension is handled badly, people pay for it. The operations team sends spreadsheet exports to customers because it cannot give them direct access. Customers call to ask about the status of an incident they could have checked themselves. And at every audit, the security manager asks whether one department could ever end up seeing another department’s data.

Why the usual approaches fall short

In practice we often see two extremes. The first is a separate instance for every customer. The data is separated, but operations fall apart. Infrastructure shared by several customers has to be recorded several times, nobody sees dependencies across instances, and every upgrade has to be repeated.

The second extreme is a single instance without real separation. Either customers are not allowed into the tool at all, or separation relies on filters and naming conventions. That works until the first configuration mistake. Filters are easy to bypass, forget or copy incorrectly when a new user is set up.

Both paths end in the same place: customers have no direct, secure view of their services, and the provider spends time on manual communication instead of running operations.

How to think about separation

Customer data separation should be a property of the platform, not a matter of administrator discipline. A few principles that work for us:

  • Separate at the data level, not the screen level. If a user lacks permission, the data is never returned. Hiding a column is not separation.
  • Make scope part of the role. A role defines not only what a user may do but also over what: everything, one customer, one team or a single item.
  • Include costs in the same model. Financial data is often more sensitive than technical data. Separation has to cover it too.
  • Use one identity. Signing in through corporate SSO means access is managed in one place, and a departing employee does not leave a forgotten account behind.

How Eywo Stratum handles it

We built Eywo Stratum for shared services providers that serve many customers from a single platform. Customer separation (multi-tenancy) is part of the data model.

A customer user sees only their own customer’s data. That applies to CMDB items, incidents, requests, changes and costs alike. When one department opens its cost overview, it sees its own business services and projects, not another department’s figures. The provider’s internal team works across the whole platform and sees shared infrastructure and cross-customer dependencies.

Permissions are managed through scoped roles. The platform has 14 roles, and each is assigned with a scope of everything, customer, team or item. A customer’s operations lead can hold the same role as an internal team lead, simply limited to their own customer. A RACI matrix shows who is responsible for what, and the platform checks that those responsibilities match the permissions people actually have.

Sign-in goes through SSO (Cloudflare Access), so access follows corporate identity. Integrations and service accounts use API tokens that are not tied to a specific person. Every action, including permission changes, is written to an audit trail retained for five years.

For the provider, this ends the era of manual exports. Customers can check the status of their incidents, their SLA performance or their monthly costs on their own. The operations team can focus on operations, and the security manager has a clear answer to the question “who can see what?”

Conclusion

A shared platform and separated data are not mutually exclusive. But separation has to be built in, not bolted on. When the platform itself enforces who works with which data, a provider can open the tool to its customers and still go home with a clear head.

Customer data separation is included in the Enterprise edition.

Eywo Stratum Enterprise
For shared-service providers and large organisations.

Compare editions →