Hi All. Our company is in the outsourcing business, supporting over a hundred clients. I'm now looking for a new internal approach on customer documentation such as operational manuals, technical configurations etc. We're allready using confluence for internal documents and WINs. The idea would be, to use confluence also for customer documentation, since our staff is already familiar with confluence (and also with the Breeze DMS Plugin installed). It would have many advantages going down that road. However, GDPR compliance, confidentiallity and access security topics are currently the main killer for that approach. Our internal IT department did an evaluation years ago and came to the conclusion, that Confluence can't be configured in such a way, that our clients can be fully separated from each other (even with separate spaces) to ensure data protection and confidentiallity. That was years ago, and I'm hopeful that this may have changed in the meantime, so that I can challenge our IT to take another potential look into such a migration. The following requirements are a given must: * Each of our customers must be configured in a separate space (check) * That space must be accessible for ...* our internal customer support teams (restricted) * For registered (restricted) customer personell (external) * As for confidentiality reasons and GDPR compliance, it is absolutely essential, that no customer can neither see nor access information on other customer spaces, which includes that they can't see ...* any other spaces configured in our confluence setup: they can only see and access their own space * any users assigned to other spaces (no names, emails, whatsoever) In order to go ahead and initiate another internal assessment on the use of confluence for that purpose, I would need a statement from confluence that the stated requirements can be fullfilled. Note: I'm not a confluence specialist, I'm only a (power) user which also happens to be responsible for internal Service Improvement. So please forgive me if I may ask things that may be obvious to the confluence specialists out there ;-) Looking forward on qualified feedback on this topic. Thanks in advance. Pat

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

GDPR compliance for Multiclient Use of Confluence

Patrick Geering

Hi All.

Our company is in the outsourcing business, supporting over a hundred clients.

I'm now looking for a new internal approach on customer documentation such as operational manuals, technical configurations etc.

We're allready using confluence for internal documents and WINs. The idea would be, to use confluence also for customer documentation, since our staff is already familiar with confluence (and also with the Breeze DMS Plugin installed). It would have many advantages going down that road.

However, GDPR compliance, confidentiallity and access security topics are currently the main killer for that approach. Our internal IT department did an evaluation years ago and came to the conclusion, that Confluence can't be configured in such a way, that our clients can be fully separated from each other (even with separate spaces) to ensure data protection and confidentiallity. That was years ago, and I'm hopeful that this may have changed in the meantime, so that I can challenge our IT to take another potential look into such a migration.

The following requirements are a given must:

Each of our customers must be configured in a separate space (check)
That space must be accessible for ...
1. our internal customer support teams (restricted)
2. For registered (restricted) customer personell (external)
As for confidentiality reasons and GDPR compliance, it is absolutely essential, that no customer can neither see nor access information on other customer spaces, which includes that they can't see ...
1. any other spaces configured in our confluence setup: they can only see and access their own space
2. any users assigned to other spaces (no names, emails, whatsoever)

In order to go ahead and initiate another internal assessment on the use of confluence for that purpose, I would need a statement from confluence that the stated requirements can be fullfilled.

Note: I'm not a confluence specialist, I'm only a (power) user which also happens to be responsible for internal Service Improvement. So please forgive me if I may ask things that may be obvious to the confluence specialists out there ;-)

Looking forward on qualified feedback on this topic.

Thanks in advance. Pat

Accepted answers

Kristian Klima_gtcuat

Hi @Patrick Geering

There could be two solutions:

One

Multi-confluence setup within your Atlassian org. One micro-confluence per client. Admittedly, this would work better on Confluence Enterprise, but it's still doable on Standard, albeit with a mild discomfort.

Two

You remain on a single Confluence

use an marketplace app to make client documentation accessible for reading
use Confluence guest roles to allow your clients to access exactly ONE space. A single guest can access only one space at a time and they cannot '@mention' users, which means it's unlikely they'd come across users from other companies

So about that app - it's Scroll Viewport by K15t and, unlike pretty much all 'theme' apps, it has one magical property - it builts a documentation site OUTSIDE of Confluence and you can controll access to that site via SSO.

In other words, you can built a specific Viewport-based documentation site for each client and control access to the site via SSO configured in such a way that only users from Client A would be able to look at the Client A Viewport site.

Select users from Client A would have Guest roles in the corresponding Client A's space on your Confluence.

Collateral benefits:

To view the viewport site behind SSO, users DO NOT NEED a Confliuence seat.
Viewport site for client could be on their own respective domains and design and branding.

This is our site built with Viewport from a Confluence space - https://docs.emplifi.io/ (our site is intentionally public but we do have an internal site behind SSO).

I think the second option would work best in your scenarios as it's easily scalable (you can create any number of Viewport sites). Happy to chat if you wanna learn more.

(the only other app that can do that, to my best knowledge, is Instant Websites by Glintech.)

All comments

Chu Dam

Hi @Patrick Geering

Well this is a classic usage of Confluence and spaces... I don't see any problem fulfilling your need here.

You just need to carefully configure customers accounts using groups, and base each customer space permissions based on the proper groups. Restricting space access by removing the global user group, and adding each group for each customer in the proper space permissions...

Confluence allows to restrict access to a space with permissions since Confluence exist I think...

To learn more about Space permissions: https://support.atlassian.com/confluence-cloud/docs/what-are-space-permissions/

I hope this helps.
Dam

marc -Collabello--Phase Locked-

Once you are a user in Confluence, you can mention users in other spaces, and thus see that they are users in the Confluence installation. That means once a customer of yours has access to a single space, they can check other users in other spaces, even if they have no access to the other spaces.

Chu Dam

aaah yes true... I forget about that sorry

this can be a problem in this case here.

the other approach will be to have a dedicated Confluence site for each customers, but this can cost quite a lot of licence fees.

Dam.

Kristian Klima_gtcuat

Hi @Patrick Geering

There could be two solutions:

One

Two

You remain on a single Confluence

use an marketplace app to make client documentation accessible for reading
use Confluence guest roles to allow your clients to access exactly ONE space. A single guest can access only one space at a time and they cannot '@mention' users, which means it's unlikely they'd come across users from other companies

Select users from Client A would have Guest roles in the corresponding Client A's space on your Confluence.

Collateral benefits:

To view the viewport site behind SSO, users DO NOT NEED a Confliuence seat.
Viewport site for client could be on their own respective domains and design and branding.

This is our site built with Viewport from a Confluence space - https://docs.emplifi.io/ (our site is intentionally public but we do have an internal site behind SSO).

I think the second option would work best in your scenarios as it's easily scalable (you can create any number of Viewport sites). Happy to chat if you wanna learn more.

(the only other app that can do that, to my best knowledge, is Instant Websites by Glintech.)

Patrick Geering

Hi Kristian.

Thanks for your fast response. Sounds both interesting. However ...

Micro-Confluence per Client would be far too complex to handle, as we have some 150+ customers. Which means, we would have to manage as many confluence instances as we have customers. I don't believe that would be very practicable with that amount of instances. Beside the cost factor, which would (most likely?) increase substantially for such a solution, I assume? That wouldn't be something that I could sell internally, that would ruin the business case.

The second option sounds at the first glance promising. I will have a look into it. The obvious drawback with that option which strikes me right now is, that we'd loose our document management system if we don't handle the documentation within confluence. We have implemented the Breeze DMS Solution in order to manage our documents in compliance with the given quality requirements set forth internally and by our customers. I assume that viewport solution doesn't include a document control/management system similar to breeze?

Regards, Pat

Patrick Geering

Hi Marc and DAM.

Yes, that user mentioning is exactly one of the issues that I currently see. As we have a NDA with most of our clients, that would definitely work against the confidentiality part. And of course it would also be an issue in regard of GDPR compliance. I'm not sure if eMail aliasing would work, but as confluence itself sends the eMails, that is to my knowledge not supported in confluence.

And I'm not quite sure, if users, even thought they can't access any other workspaces, are not able to see the other workspaces in the confluence instance. That again would be the same issue as with the user visibility.

Using an instance per customer is not feasible as I explained in my answer to Kristian Klima (https://community.atlassian.com/forums/Confluence-questions/Re-Re-GDPR-compliance-for-Multiclient-Use-of-Confluence/qaq-p/2998309/comment-id/339236#M339236)

Regards, Pat

Kristian Klima_gtcuat

@Patrick Geering

You will handle everything in Confluence, only the 'consumption' level will be in Viewport.

I actually tested Viewport with B1nary's Breeze and it works - I had it configured using the Breeze's option of the secondary space for edits (approvals etc.) and discussed the options with Adrian Hulsmann at length

So you can keep conducting your workflow/DMS in Breeze

In this scenario, Viewport would use your primary space as a content source, you'd use Breeze's working space (secondary space) for updates).

This will assure that Viewport would only work with final, approved version.

I think Adrian would not mind jumping on a call to discuss the details of the configuration (especially as I haven't worked with Breeze for a couple of months now).

Patrick Geering

Hi DAM.

As explained, the user mentioning is one of the issues, the other is the visibility of the spaces. Access can be restricted, correct, however not the visibility of it. At least that is what I experience in our current setup. (even thought I have no access to the HR Workspace, I can see that there is such a workspace. That is unfortunately not in line with the confidentiality requirements set forth). But maybe there's a solution to it by using another configuration approach. But keep in mind, we're talking about 150+ spaces, so potentially additional admin efforts coming with another setup, would have to be more or less reasonable.

Regards, Pat

Patrick Geering

Hi Kristian.

Thanks for feedback. Sounds terrific indeed. And knowing Adrian, he certainly wouldn't mind to jump into a call. I had some very infusing calls with him in the past regarding Breeze :-)

However, before we do so, I need to include a few more internal stakeholders in developing the idea and a potential business case. Some of the topics I need to clarify are hosting topics, like do's and dont's etc.

Do you know by any chance, how/where the helpcenter websites of Viewport are hosted? (InstantWebsites are hosted on AWS as I've learned. And that in any case, regardless if you're planing with a local host, via CNAME)
We're actually using SNOW as a helpcenter solution, and are currently amidst an internal project to restructure/simplify SNOW from scratch. So idealy, I'd see to have the created websites tied to the customer portals in SNOW, that would ease admin efforts regarding access and confidentiality topics (if that's possible with viewport?). So I need to discuss it with the SNOW project team on one side, and clarify for Viewport

I'll get back to you as soon as possible

Regards, Pat

marc -Collabello--Phase Locked-

One other thing: If you onboard your clients onto Confluence, all user data will be stored in the US, even if you enable data residency in Europe for your Confluence instance. See https://support.atlassian.com/security-and-access-policies/docs/understand-data-residency/ and especially look for the term "user account information". This might have compliance implications for your business.

Sheba Satan

Interesting 🤔

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

confluence

cloud

confluence-cloud

security

gdpr

confidentiality