ThinkBig: Compliance and Security & Compliance
Description
The Secure and Protect stages focus on identifying, managing, and remediating application security vulnerabilities. The Compliance group (under the Manage
stage) focuses on raising awareness and visibility of the compliance state of GitLab groups and projects. The reason that the word compliance
was originally added to Security
in this section of the navigation was to account for License Compliance.
Some changes have come up recently that has led to a few of us discussing the similarities and differences between Compliance and Security & Compliance. Things to note:
Personas, workflows, and IA
The Compliance group's primary persona is Cameron, the Compliance Manager, who makes sure that "the organization’s use of third-party software adheres to internal company policy. This can consist of the SDLC, access management, change management, and a multitude of other policies. I interface regularly with our internal compliance, audit, and/or security teams to deliver the information they need for our organization’s compliance program."
The other personas for Compliance are Sam, Security Analyst, Sidney, Systems Administrator, and Rachel, Release Manager.
Secure focuses primarily on Sam, the Security Analyst and Sasha, Software Developer. Sasha will interact with Secure features primarily through the security widget in the MR rather than any of the pages under Security & Compliance
.
This brings up a few questions:
-
What is the workflow of Sam, the Security Analyst? It seems as though some, but not all, organizations will have a security analyst that is involved in both compliance and security. With the recently completed Static Analysis CMS, one finding from speaking with our internal (GitLab) security engineers and software developers was that none of them had any interaction with compliance, and so we ended up discarding the task associated with compliance. Is this something unique to GitLab? Does it depend on the organization size or structure? If Sam is doing Compliance work, should their JTBDs in our handbook be updated to reflect that?
-
How does the UX (features, information architecture, workflows) of this section feel to Sidney and Rachel? Do they interact with any other features under
Security & Compliance
? What should each persona have access to; i.e., is there a permissions conversation that needs to take place here? -
The recent addition of
Audit Events
in the Security & Compliance subnav has raised a few questions: It's a bit of a black sheep when you consider the relationship between the other subnav items (security dashboard, vulnerability report, on-demand scans, dependency list, license compliance, threat monitoring, and configuration). Apparently this was moved out from underSettings
for permission reasons and because the team didn't really consider it as a "setting" at all. Is this the only area that was considered? Could it be categorized under Analytics? (A card sort could help answer this if it wasn't already tested with users.) Should there be a devoted Compliance area that houses things like Audit Events? What does it mean as we continue to build out the Security Dashboard (see project level security heat map and security control status widget) and the compliance team builds out their Compliance Dashboard? -
Group-level Compliance Dashboard (currently under a feature flag): @aregnery and I discussed earlier about how this isn't really a dashboard but more like a report, and it's named
Compliance
in the nav. Is this confusing for users of License Compliance? -
Best practice UX typically keeps settings/ configuration at the bottom of a menu, and as we've added more items to the subnav, we (in Secure and Protect) have generally been in alignment in keeping
Configuration
at the bottom of the menu. A simple MVC here is to rearrange the subnav, puttingConfiguration
back at the bottom. It's worth discussing what the order of these items should be, assuming we keep it as-is. Are there any more changes we can expect to the nav in 2021 from either Secure, Protect, or Manage/ Compliance?
Working relationship between stages/ groups
-
How did Compliance become categorized as part of Manage rather than Secure and/or Protect? Does it make sense to keep our current organization structure when we share a part of the navigation? What should our relationship look like moving forward, considering things like syncs (Secure and Protect have a PM/ UX sync every 2 weeks), Slack channels, and pinging each other on issues?
-
What is the future of Compliance? How might it overlap or even conflict with the future plans of Secure and Protect?
@aregnery @mattgonzales @jeremy @matt_wilson @sam.white @NicoleSchwartz @tmccaslin @stkerr @derekferguson @jmandell @david @cam.x @andyvolpe @annabeldunstone