Engagement Security Controls — Narrative Consulting

The following controls apply to every Narrative Consulting engagement regardless of scope, duration, or client size. These are not aspirational standards — they are operational requirements. Engagements cannot proceed if these controls cannot be implemented.

Authentication Required

Multi-factor authentication is required on every client-provisioned account used during the engagement. Password-only access is never acceptable, with no exceptions.

Authentication requirements:

MFA must be enabled on all accounts before the consultant begins any work
Approved MFA methods: TOTP authenticator apps (Authy, Google Authenticator, Microsoft Authenticator), hardware security keys (YubiKey), push-based MFA (Duo, Okta Verify)
SMS-based MFA is accepted only when no stronger method is available, and is flagged in the engagement report as a finding
Biometric authentication on its own is not accepted as MFA for privileged accounts
Shared accounts requiring MFA are not permitted — consultant must have a dedicated account
Privileged access (admin, global admin, root) requires hardware MFA or TOTP — no exceptions

Secure Channels Required

All work is conducted over encrypted, authenticated communication channels. No unencrypted protocols are used for any engagement-related activity.

All web-based access over HTTPS (TLS 1.2 or higher)
Remote system access via SSH (ed25519 or RSA-4096 keys preferred) or client-approved VPN
Video calls via Google Meet, Microsoft Teams, or Zoom — recorded only with explicit consent
File transfers via SFTP, client-provisioned secure portals, or encrypted cloud storage (SharePoint, OneDrive for Business)
Consumer file sharing services (personal Dropbox, Google Drive) prohibited without explicit written approval
All connections from public networks require VPN

Scoped Access Required

All access is scoped to the minimum required for the engagement. Access is never granted in bulk, and privileged access is time-limited to specific tasks.

Access request submitted in writing before provisioning begins, with explicit justification
Read-only access used wherever possible; write access requested only when required
Privileged roles (admin, owner) granted only for specific tasks and removed immediately after
All provisioned access documented in an engagement access log updated throughout the project
Access to systems outside the defined scope is declined even if offered
Service account permissions follow least-privilege and are documented in the deliverables

Activity Logging Required

Every system accessed, action taken, and change made during the engagement is logged and reported. Clients receive a complete activity log as part of their engagement deliverables.

Consultant maintains a running activity log throughout the engagement
Log entries include: timestamp, system accessed, action taken, outcome, and approval reference where applicable
Client is asked to enable and preserve native audit logs in all systems accessed
Activity log is finalized and delivered within 5 business days of engagement close
Log format is client-compatible (CSV or PDF as preferred)
Any unexpected system behavior or errors encountered during engagement are documented and reported

Change Management Required

No production changes are made without documented client approval. All changes are tested in non-production environments first, and emergency changes follow pre-agreed break-glass procedures.

All planned changes documented in a change request before execution
Change requests include: scope of change, risk assessment, rollback procedure, and approval signature
Changes are tested in dev/staging environment before production deployment
Production changes are scheduled during client-approved maintenance windows where possible
No changes made outside agreed scope without written approval
Break-glass procedure (for emergency production access) defined and agreed in engagement charter before work begins
Post-change validation performed and documented

Separation of Environments Required

Development, staging, and production environments are treated as separate security domains. Access to one does not imply or require access to another.

Separate access credentials provisioned for each environment
Production data is never used in development or testing without explicit written approval and appropriate anonymization
Findings from non-production environments are validated in the target environment before final documentation
Infrastructure changes (IaC, Terraform, etc.) reviewed in non-production before production apply
No lateral movement between environments — each access is independently scoped and approved

Incident Response Required

Security incidents discovered during an engagement are reported immediately. Consultant action stops on affected systems pending client direction. A written assessment and containment recommendations are provided within 24 hours.

Security incidents reported to client security contact within 2 hours of discovery (business hours) or first business morning (after hours)
Preliminary verbal notification followed by written incident report within 4 hours
Consultant work on affected systems paused pending client instruction
Evidence preserved — no remediation actions taken without client approval
Containment options and recommendations delivered within 24 hours
Full written incident report delivered within 72 hours
Post-incident review offered at no additional charge