Skip to main content

Native Markdown Wiki for Google SecOps

  • June 10, 2026
  • 2 replies
  • 65 views

0xM4XDF1R
Forum|alt.badge.img+4

Hi everyone, I have a feature proposal that I believe would greatly benefit our workflows.

Every SOC team relies heavily on documentation. On any given day, we need quick access to:

  • Playbooks and Standard Operating Procedures (SOPs)

  • Guides and how-tos

  • Internal systems documentation

  • Detailed reporting for major incidents

  • Reference lists

  • The list goes on

We all want Google SecOps to truly function as a "single pane of glass" for our analysts. Currently, forcing them to context-switch and jump between SecOps and external tools like Loop, OneNote, Confluence, or an external wiki breaks focus and disrupts the workflow.

Implementing a simple, native Markdown-based wiki directly into Google SecOps seems like a straightforward solution with massive benefits. Having all security-critical documentation residing in the primary operational tool would be incredible.

Imagine the potential: you could even search and automatically pull relevant internal documentation directly into specific cases and alerts based on tags.

I’d love to hear if others are missing this, and if this is something we could see on the roadmap!

2 replies

_K_O
Forum|alt.badge.img+13
  • Silver 2
  • June 12, 2026

I can’t speak for all teams, but we specifically centralize our docs in something like Confluence because other teams, auditors, external stakeholders, etc. frequently need access to our SOC documents.

That said, I love the idea of automatically pulling relevant docs into specific cases based on tags. Imo, instead of a native wiki, a great middle-ground FR for the roadmap might be robust integrations/API connectors to tools like Confluence, Loop, OneNote, etc. That way, we get the 'single pane of glass' workflow in Google SecOps without creating another isolated documentation silo.


AnimSparrow
Forum|alt.badge.img+6
  • Bronze 5
  • June 17, 2026

We found something that works really well for our team. We built an API connected to our documentation stored in SharePoint/OneNote and other cloud-based tools. Based on tags, we pull the HTML output directly into an HTML widget at the bottom of the page.

The widget always shows two options:
- **"Show Documentation"** — an inline hide/show toggle (hardcoded HTML)
- **"Jump to Documentation"** — a direct "open in new tab" link

It is just shown in smalles possible html widget at the bottom of the page - when you need it you just use extend icon to have it more fullscreanish way.

It wasn't particularly difficult to implement. The only real requirement is having some logic in the first playbook that is responsible for view - a single action block written in the IDE - to fetch the relevant solution based on tags. Tag management itself is straightforward and can be handled via data tables, which keeps the whole thing easy to maintain as your documentation grows.

Downsize might be if you have ticket that it’s there for more than 10days and you activly updated docs but I would say if this would be an issue there probably can be some job or refresh button to fix it :)