Add pattern: Transparent Catalog of Privacy Controls and Posture - #931
Add pattern: Transparent Catalog of Privacy Controls and Posture#931shrutibist wants to merge 5 commits into
Conversation
|
The failing Link Checker check appears unrelated to this PR, it's flagging a 403 from oreilly.com elsewhere in the repo, not from my new file. |
spier
added
the
📖 Type - Content Work
|
Hi @shrutibist. Thank you for opening this (and the other) PRs to cotnribute your pattern content! We are currently trying to train additional maintainers to help with the review of these PRs. Therefore it may be a little bit slower than usual but it is for the greater benefit of increasing the number of maintainers of our repo, so I hope it is ok for you to wait a bit longer :) Some general questions from me, just out of curiosity:
We aim to provide specific feedback to your PR within the next week. In the meantime if you have any questions, please ask! |
|
Hello Sebastian,
If you have more questions, I will be happy to help. Thanks. |
|
@shrutibist amazing, thank you for sharing this context. I am looking forward to learning more about this patterns, so please stay tuned for content-feedback from me and others. Also just as a heads up: |
|
Just a quick update @shrutibist, we are aiming to provide feedback on this PR by middle of next week. Thank you for your patience! |
|
@shrutibist one other thought that I had about this pattern: The problem that is being solved with this pattern is a privacy/security issue, and the solutions applies elements of InnerSource. If that is correct, then we need to think about how we could adapt it, to become more clearly about an InnerSource problem. Most other patterns (I think) are solving a problem that is inherent to the InnerSource-collaboration style. This pattern here could be considered a "good first project" of sort, when you are looking for a project that you can practice the InnerSource-collaboration style with. To explore this further, you could ask your AI agent of choice this question:
I used ChatGPT, and found some interesting angles in there. |
|
Yeah, fair point, and honestly this was nagging at me too. I think the strongest InnerSource angle here is buried in the second story- three teams building their own PII redaction logic because there was no shared place to define and refine that control. That's a real duplication problem that InnerSource is meant to solve. The Posture Register piece is different. It's restricted-access by design, so calling that part InnerSource is a bit of a stretch on its own. But I have seen this same hesitation in regular source code repos too, where owners aren't comfortable giving full access right away for various reasons. Our general recommendation there is to start with restricted access when full view access isn't realistic yet, but still make the repo discoverable, and move toward view-only access as trust builds. I think the Register can lean on that same progression rather than needing to be Open from day one. I want to take another pass and lead with the Catalog/duplication problem instead of the audit visibility angle, and either treat the Register as a secondary piece or just split it into its own pattern about the openness versus sensitivity tradeoff. Let me rework it and repost. Happy to hear which direction people think makes more sense before I do the rewrite. |
| @@ -0,0 +1,133 @@ | |||
| # Title | |||
There was a problem hiding this comment.
| # Title | |
| ## Title |
|
|
||
| Transparent Catalog of Privacy Controls and Posture | ||
|
|
||
| # Patlet |
There was a problem hiding this comment.
| # Patlet | |
| ## Patlet |
|
|
||
| Large organizations often have no standardized, discoverable set of privacy controls that engineering teams can implement against, and no reliable visibility into which teams actually comply with existing privacy requirements, so risk stays hidden until an audit or incident surfaces it. Publish a version-controlled Privacy Controls Catalog as the shared baseline (open to engineering-proposed refinements but authored by privacy/legal), and maintain a separate, access-tiered Privacy Posture Register through the same pull-request and trusted-committer workflow, so compliance becomes a continuously queryable property of the codebase instead of a periodic audit exercise. | ||
|
|
||
| # Problem |
There was a problem hiding this comment.
| # Problem | |
| ## Problem |
|
|
||
| These two problems compound each other: without a common, structured baseline, there is no consistent schema to report compliance against, which makes visibility even harder to establish. | ||
|
|
||
| # Story |
There was a problem hiding this comment.
| # Story | |
| ## Story |
|
|
||
| A privacy manager receives a customer security and privacy questionnaire ahead of a contract renewal. One section asks not just whether the product uses generative AI, but how: what it's used for, what data it touches, and what safeguards are in place. The privacy manager knows GenAI is used somewhere in the product, but not in what capacity, for which features, or on what data. What follows is several days of chasing the product manager and engineering team for answers before the questionnaire can be answered accurately. The customer is left waiting on a response that should have taken minutes, for information that already exists somewhere in the organization, just not anywhere the privacy manager could find it. This is the same visibility gap as the audit fire drill above, just triggered by an external customer question instead of an internal audit, and made worse because the missing information is about what's deployed at all, not only whether a known control is met. | ||
|
|
||
| # Context |
There was a problem hiding this comment.
| # Context | |
| ## Context |
|
|
||
| This pattern is not simply a relabeling of general InnerSource security-sharing practices. Security-related sharing already benefits from mature, largely automated visibility tooling (scanners, SIEMs, dependency graphs), so the open-source-inside-the-firewall question for security is mostly "how open should access to already-visible information be." Privacy starts a step earlier: the information often isn't reliably visible or standardized at all, regardless of access level, because the tooling and organizational habits that make security status legible haven't been built for privacy. This pattern's two-repository structure exists specifically to close that earlier gap, creating the standardized, structured record in the first place, before the same access-tiering logic used in security contexts can even be meaningfully applied. | ||
|
|
||
| # Related Patterns |
There was a problem hiding this comment.
| # Related Patterns | |
| ## Related Patterns |
| * [Transparent Cross-Team Decision Making using RFCs](https://patterns.innersourcecommons.org/p/transparent-cross-team-decision-making-using-rfcs.md): offers a complementary mechanism for proposing new or changed controls in the Catalog with visible, structured cross-team input before a trusted committer merges them. | ||
| * [Balancing Openness and Security](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns/1-initial/balancing-openness-and-security.md): a more general pattern addressing how Security/Legal can be embedded in InnerSource collaboration through explicit sharing levels and sensitivity classification. This pattern specializes and extends that idea for privacy specifically. Unlike security, privacy typically lacks the mature, largely automated visibility tooling (scanners, SIEMs, dependency graphs) that lets security status be classified and shared at the right level in the first place. This pattern's two-repository structure exists to first create a standardized, structured record of privacy controls and posture, a step security's tooling already provides, before the same access-tiering logic can be applied. | ||
|
|
||
| # Known Instances |
There was a problem hiding this comment.
| # Known Instances | |
| ## Known Instances |
|
|
||
| TBD | ||
|
|
||
| # Status |
There was a problem hiding this comment.
| # Status | |
| ## Status |
|
|
||
| Initial | ||
|
|
||
| # Author(s) |
There was a problem hiding this comment.
| # Author(s) | |
| ## Author(s) |
|
|
||
| Shruti Bist | ||
|
|
||
| # Alias |
There was a problem hiding this comment.
| # Alias | |
| ## Alias |
3 participants
A new InnerSource pattern addressing the lack of standardized privacy controls and lack of visibility into privacy compliance posture across engineering teams, solved via a two-repository model (open Controls Catalog plus access-tiered Posture Register.