Documentation for enterprise sales: security docs, SSO guides, and compliance pages

Your AE is 40 minutes from close on a six-figure deal when the prospect’s security team asks for the SSO setup guide, the sub-processor list, and “something on your admin permissions model.” Your AE Slacks engineering. Engineering points to a Notion page last touched by someone who left the company. The page describes an SSO flow you replaced two quarters ago. The deal doesn’t die from this — it just slips two weeks while someone reconstructs the truth from a Slack thread and a squint at the codebase. Multiply that by every enterprise deal in the pipeline and you have a real cost, paid entirely in calendar time nobody budgeted for.

This is not a sales enablement problem you solve with a better deck. It’s a documentation problem, and it has a specific, narrow shape: a small set of pages that security reviewers and IT admins read closely, that go stale silently, and that nobody owns until a deal is stuck on them.

The docs your AE gets asked for in every enterprise deal cycle

Enterprise procurement follows a script, even when nobody’s read the same script twice. Once a deal crosses a certain size, it routes through a security review, and that review asks for the same handful of artifacts almost every time:

1. An SSO/SAML (or OIDC) setup guide — proof you support their identity provider and a walkthrough of the exact config.
2. A security and compliance page — certifications, data residency, encryption, sub-processors.
3. Admin and permissions documentation — who can see what, how roles are assigned, whether access can be enforced centrally.
4. Audit log and data retention details — often folded into the security page, sometimes its own doc.
5. An SLA or uptime page — less about content depth, more about existing at all.

None of these are hard to write once. What makes them expensive is that they’re read by people who are paid to be skeptical, and they’re the pages most likely to drift out of sync with the product because they’re rarely on an engineer’s roadmap. A pricing page getting stale costs you nothing dramatic. A security page that claims you don’t support SCIM six months after you shipped it costs you a stalled deal and an awkward call where your AE has to explain why the docs were wrong.

The fix isn’t “write more docs.” It’s treating this specific set of pages as sales infrastructure — as load-bearing as your pricing page, reviewed on the same cadence as your codebase changes, and owned the way you’d own a production service.

SSO/SAML setup guides — what security teams actually check

Security reviewers reading your SSO guide are not casually skimming. They’re checking whether the integration will actually work with their IdP before they greenlight a contract, and they read for specifics, not reassurance. A guide that says “we support enterprise SSO” tells them nothing. A guide that shows the exact metadata, attribute names, and provisioning behavior tells them everything.

At minimum, your SSO guide needs to show:

• Whether you support SP-initiated, IdP-initiated, or both flows.
• The exact SAML attributes you expect (and what happens if one is missing).
• Your ACS URL, Entity ID, and NameID format, not just “ask support for these.”
• Whether you support Just-In-Time provisioning, SCIM, or both, and what happens to a deprovisioned user’s access.
• Session and re-authentication behavior — does revoking access at the IdP actually kill an active session?

Here’s the difference between a guide that stalls a review and one that clears it:

❌ Vague, unreviewable:

To set up SSO, go to Settings → Security and follow the prompts to connect your identity provider. Contact support if you have questions.

✅ Specific, self-service:

# GitDoc SAML 2.0 configuration reference
sp_entity_id: https://dashboard.gitdoc.ai/saml/metadata
acs_url: https://dashboard.gitdoc.ai/saml/acs
name_id_format: urn:oasis:names:tc:SAML:2.0:nameid-format:emailAddress

required_attributes:
  email: user.email          # maps to primary login identifier
  firstName: user.givenName
  lastName: user.familyName
  role: user.department      # optional — drives default role if JIT provisioning is on

provisioning:
  jit_enabled: true           # creates user on first successful login
  scim_enabled: true          # /scim/v2 endpoint, bearer token auth
  deprovision_on_idp_removal: true   # session revoked within 5 min of IdP-side removal

That second version answers the questions a security engineer is actually going to ask before they’ve had to ask them. It also happens to be the kind of content that goes stale fastest — attribute names change, a new IdP gets certified, deprovisioning behavior gets tightened — which is exactly why it needs an owner and a review trigger tied to the actual auth code, not a “review docs quarterly” calendar reminder that gets ignored the first time a sprint runs long.

The security & compliance page — SOC 2, data residency, sub-processors

If the SSO guide is what gets technically verified, the security and compliance page is what gets forwarded to legal and procurement without much scrutiny of the details — which makes accuracy even more important, because errors here don’t get caught in a live technical review, they get caught six months later when an auditor asks your customer’s compliance team to reconcile what they were told against what’s actually true.

A security page that survives scrutiny covers:

• Certifications and audit status — SOC 2 Type II, ISO 27001, whatever applies, with the actual report available under NDA, not just a badge image.
• Data residency — where data is stored, whether region selection is available, and whether that’s contractual or best-effort.
• Sub-processor list — every third party that touches customer data (hosting, email, analytics, error tracking), kept current, because this list is often contractually required to stay accurate and customers are notified of changes.
• Encryption — at rest and in transit, with the actual standards named (AES-256, TLS 1.2+), not “bank-level encryption.”
• Breach notification commitments and data retention/deletion policy — how fast you notify, what happens to data on contract termination.

The sub-processor list in particular is a page that rots fast because it changes every time you add a vendor, and it’s exactly the kind of change an engineer makes (swapping an email provider, adding a new hosting region) without thinking “this is a docs update.” That’s the gap GitDoc is built to close for content tied to the codebase and infra config — when the sub-processor list is meant to reflect what’s actually wired into production, syncing the docs to the source of truth beats trusting someone to remember. If you want to see how that loop works end to end, gitdoc.ai walks through it.

Admin and permissions docs — the boring pages that unblock big contracts

Nobody gets excited about writing the roles-and-permissions page. It’s also one of the first things an IT admin reads before they’ll let a tool anywhere near their org, because it answers the question that actually determines whether they can manage risk: can we control who does what, centrally, without trusting every individual user to behave.

This doc needs to be concrete enough that an admin can plan their rollout from it, not just get a vague sense of “yes we have roles.” A permissions matrix, laid out plainly, does more work than a paragraph of prose:

{
  "roles": {
    "owner": {
      "manage_billing": true,
      "manage_sso": true,
      "manage_members": true,
      "edit_docs": true,
      "publish_docs": true,
      "view_audit_log": true
    },
    "admin": {
      "manage_billing": false,
      "manage_sso": true,
      "manage_members": true,
      "edit_docs": true,
      "publish_docs": true,
      "view_audit_log": true
    },
    "editor": {
      "manage_billing": false,
      "manage_sso": false,
      "manage_members": false,
      "edit_docs": true,
      "publish_docs": false,
      "view_audit_log": false
    },
    "viewer": {
      "manage_billing": false,
      "manage_sso": false,
      "manage_members": false,
      "edit_docs": false,
      "publish_docs": false,
      "view_audit_log": false
    }
  },
  "sso_enforcement": "org-wide, enforceable by owner/admin",
  "scim_role_mapping": "supported via IdP group attribute"
}

Pair that with plain answers to the questions admins ask next: can we force SSO org-wide so local passwords stop working, is there an audit log and how far back does it go, can we bulk-remove users on offboarding, and does a role change take effect immediately or on next login. None of this is glamorous content. It’s also the exact content that unblocks a signature, because it’s what the person with veto power over the purchase actually reads before they say yes.

Keeping sales-critical docs owned by someone, not orphaned

The pattern behind every stalled deal in this category is the same: the doc existed, it was even good when it was written, and nobody was accountable for it afterward. It got written by whoever set up SSO the first time, or by an engineer closing out the SOC 2 project, and then it sat there while the product moved on. Ownership defaulted to nobody, which in practice means it defaulted to “whoever the AE can find in Slack when a deal is stuck.”

Fixing this takes two things, and neither of them is “try harder”:

1. An explicit owner per page, named, not implied. Security page: whoever owns compliance. SSO guide: whoever owns auth. Admin/permissions doc: whoever owns the account model. If a page doesn’t have a name attached, assume it’s already stale.
2. A trigger that ties the doc to the thing it describes, so it doesn’t rely on that owner remembering. When the SAML attribute mapping changes in code, the SSO guide should flag for review in the same motion — not six months later when a prospect’s security engineer catches the discrepancy first.

That second point is the one most teams skip, because it requires infrastructure, not just goodwill. This is the specific gap GitDoc closes: it watches your repo, and when a change touches something a sales-critical doc describes — an auth flow, a permissions check, an infra config that affects the sub-processor list — it drafts the update and puts it in front of the owner for a quick review, instead of waiting for someone to notice the docs are wrong during a live deal. The review stays human. The noticing stops being manual.

Enterprise deals don’t stall because your product isn’t ready. They stall because the three or four pages a security team actually reads say something that was true two quarters ago. Fix the ownership and the sync, and those pages stop being a tax on every deal cycle.

GitDoc keeps your docs in sync with your codebase on every push. Start free →