Style Guide — Aulendur Cyber Policy Library¶
Voice¶
- Formal, prescriptive, dispassionate.
- No marketing. No "world-class," "robust," "leverage," "synergy," "best-in-class."
- No softeners. Not "we strive to," not "we aim to" — we do or we shall.
RFC 2119 / 8174 Keywords¶
| Keyword | Meaning |
|---|---|
| shall / must | Absolute requirement |
| shall not / must not | Absolute prohibition |
| should | Recommended; deviations require documented rationale |
| should not | Discouraged; deviations require documented rationale |
| may | Permitted; optional |
Use shall for control language. Reserve must for emphasis or where regulatory text uses it directly.
Person & Tense¶
- Third-person present for policy statements: "Aulendur shall encrypt CUI at rest using FIPS 140-2/3 validated modules."
- Second-person ("you") only in Acceptable Use Policy and end-user-facing SOPs.
Acronyms¶
- Define on first use per document: "Controlled Unclassified Information (CUI)."
- Maintain a
Definitionssection in each policy. Avoid forcing the reader to chase definitions across docs unless they are common (CUI, MFA, SSP).
Numbering¶
- Policy statements are numbered:
5.1,5.2,5.3... within the Policy Statements section. - Each statement is atomic (one obligation), testable (an auditor can evidence it), and attributable (the responsible role is identifiable).
Bad: "Aulendur shall manage user accounts appropriately." Good: "5.3 The ISSM shall review all privileged account entitlements quarterly and remove any entitlement not justified by current role assignment within 5 business days of review."
Specificity¶
- Always state: who, what, when, frequency, threshold.
- Time bounds: use calendar days unless business days is intentional.
- Replace "regularly," "periodically," "as needed" with concrete cadence.
Tables¶
Use Markdown pipe tables. Keep narrow enough to render in DOCX without spillover.
Callouts¶
> [!NOTE] DECISION POINT:— flag a judgment call for human review.> [!WARNING]— flag regulatory landmines or common audit findings.> [!TODO]— temporary; resolve before marking the doc DONE.
Cross-references¶
- Use relative Markdown links:
[Access Control Standard](../../standards/access-control-standard.md). - If the target does not yet exist, write the link AND mark
(forthcoming). Add the target toSTATUS.mdas TODO.
Control Mappings¶
Every policy ends with a control mapping table. Format:
| Framework | Control ID | Control Title | Coverage |
|---|---|---|---|
| NIST SP 800-171 R3 | 03.01.01 | Account Management | Full |
| CMMC 2.0 L2 | AC.L2-3.1.1 | Authorized Access Control | Full |
| NIST SP 800-53 R5 | AC-2 | Account Management | Partial |
Coverage values: Full | Partial | Supports. If Partial, name the companion doc that covers the rest.
Revision History¶
| Version | Date | Author | Changes |
|---|---|---|---|
| 1.0 | TBD-YYYY-MM-DD | J. Gershenson | Initial issue |
Filenames¶
- Lowercase, kebab-case.
- Numeric prefix matches
BUILD_ORDER.mddocument number, zero-padded to two digits. - Example:
01-information-security-policy.md.
Commit Discipline¶
- One document per commit (or one cohesive change set).
- Conventional commit prefixes:
policy(<dir>/<NN>):— new policystandard(<NN>):— new standardsop(<NN>):— new procedureplan(<NN>):— new planmapping:— crosswalk updatechore:— repo housekeepingfix(<file>):— corrections to existing docsaudit:— audit pass output
Words to Avoid (low information)¶
leverage, utilize, robust, synergy, best-of-breed, world-class, holistic, paradigm, ecosystem (when not literal), enable (vague sense), facilitate (vague sense), drive (as a verb meaning "cause"), ensure (when "shall" works), going forward.
Words to Prefer¶
shall, document, record, encrypt, authenticate, authorize, log, retain, destroy, review, approve, restrict, monitor, alert, escalate, report.