SSP Narrator

Generates present-tense SSP narratives in your system's voice. Assessment-grade.

Reads your system context, existing configurations, and policy docs to write SSP control narratives. Output matches the present-tense, objective-level style that CCAs and 3PAOs expect — not boilerplate, not paraphrased requirements.

Tools:readgrepglob

Frameworks:CMMC L2FedRAMP ModerateISO 27001NIST 800-171

Use case 1

SSP is overdue and you have system context but no time to write 110 narratives by hand

→ Assessment-grade narratives in your voice, naming specific tools, with evidence references and full assessment-objective coverage per control

Use case 2

An assessor flagged your narratives as 'paraphrased requirements' and you need to rewrite urgently

→ Concrete, present-tense narratives describing what your organization actually does, not what the standard requires

Use case 3

Migrating SSP from CMMC to FedRAMP and need CIS / CRM splits for every control

→ Restructured narratives with customer / cloud provider responsibility delineated per FedRAMP template, parameter values filled in

Try a sample prompt:

ssp-narrator · live demo · gemini-flash

◇ Curated sample output (real format)

AC-2 · Account Management

Implementation

Acme provisions, manages, and reviews system accounts using Okta as the central identity provider with role-based access aligned to the principle of least privilege. New account requests originate as Jira tickets in the IT-IAM project and require the requestor's manager approval plus security team review for any account with elevated privileges. Approved tickets trigger an automated workflow in Okta Workflows that creates the account, assigns the appropriate group memberships derived from the user's role and department, and provisions downstream entitlements via SCIM to AWS IAM Identity Center, GitHub, Salesforce, and Snowflake.

Account types are defined as Standard User (Okta group "Employees"), Service Account ("ServiceAccounts" — non-interactive, certificate-based), Privileged ("Admins" — JIT activation via Okta Identity Governance with 4-hour expiry), and Guest ("Externals" — quarterly justification required). All account creation, modification, and deactivation events flow to Splunk via the Okta System Log API with a 90-day searchable retention and 2-year cold storage.

Account reviews occur quarterly. The Security Operations Manager exports the active account list from Okta on the first business day of each quarter, distributes per-team reports to system owners via a Confluence workflow, and tracks reviewer attestations in the IAM-Reviews Jira project. Decisions to retain, modify, or remove are executed within 5 business days of attestation, with revocations triggered by closing the Okta lifecycle workflow. Accounts inactive for 90 consecutive days are automatically disabled by Okta and a deletion ticket is created for review.

Termination triggers immediate Okta deprovisioning via the Workday-to-Okta HR-driven workflow within 30 minutes of HR marking the employee as terminated. Voluntary departures and involuntary terminations follow the same automated path; manual override is documented when applicable.

Evidence References

1. okta-org-config-export-2026q2.json — IdP configuration showing groups, lifecycle rules, MFA policies

2. okta-workflow-account-provisioning.png — Account provisioning workflow diagram

3. okta-system-log-sample-30d.csv — 30-day account event sample for AU-2 cross-reference

4. ac-2-q1-2026-review-completion.pdf — Q1 2026 quarterly review attestation report

5. acme-iam-policy-v3.2-approved.pdf — Approved IAM policy referencing AC-2 procedures

6. workday-okta-hr-integration-config.png — HR-driven termination workflow config

Customer / Cloud Responsibility (FedRAMP CIS/CRM)

Activity	Customer (Acme)	Provider (Okta)
Define account types	X
Configure IdP	X
Maintain Okta platform availability		X
Audit logging	X (config)	X (capture)
Account review execution	X

Assessment Objective Coverage

- AC-2 [a] account types defined → Standard / Service / Privileged / Guest in Okta groups

- AC-2 [b] assignment of account managers → IT-IAM team via RACI in IAM policy §3.2

- AC-2 [c] required information → captured in Jira request form, validated by Okta provisioning workflow

- AC-2 [d] approval → manager + security for elevated, via Jira workflow

- AC-2 [e] creation/modification/deletion → automated via Okta + SCIM

- AC-2 [f] monitoring → Splunk dashboard "IAM-Live"

- AC-2 [g] notify when no longer required → Workday → Okta workflow

- AC-2 [h] authorize access → group memberships derived from role; entitlement-based via JIT for elevated

- AC-2 [i] review compliance → quarterly review process documented above

- AC-2 [j] establish/reissue → identity proofing via Workday HR record, MFA enrollment within 24h

- AC-2 [k] required information for each account → captured in Okta profile and Jira ticket

Cmd+Enter to send

← Back to agent registry