SOP-OPS-security-review-v1.0¶

1. Purpose¶

Define the security review process for new integrations, vendors, code changes, and agent capabilities before they go into production or active use. Ensures that security considerations are evaluated systematically rather than ad-hoc.

2. What Requires a Security Review¶

Work type	Review required	Trigger
New external integration (API, webhook, third-party service)	Mandatory	Before any credentials are issued or data is exchanged
New agent capability (new MCP tool, new external API access for an agent)	Mandatory	Before capability is added to agent contract or settings.json
Code change touching authentication or credential handling	Mandatory	Before merge to main
New vendor relationship (any vendor who will hold eco	monetize data)	Mandatory
Agent contract change expanding decision rights	Recommended	Before promotion to Active
New public-facing endpoint or webhook	Mandatory	Before deployment
Quarterly credential and access audit	Mandatory	Standing cadence per SOP-OPS-credential-management-v1.0

3. Security Review Procedure¶

Step 1 — Scope the review¶

security.ops identifies what is being reviewed and what the exposure surface is:

What data does this touch? (credentials, customer data, internal configs, code)
What is the attack surface? (external API, webhook, agent tool call, file write)
What is the blast radius if compromised? (isolated vs. cross-system)

Step 2 — Credential and access audit¶

For any new integration or vendor:

Confirm credentials will live in 1Password per SOP-OPS-credential-management-v1.0
Confirm the minimum-permission principle: the credential or token should have only the access it needs
Verify no credentials are hardcoded in agent prompts, config files, or session directories
Confirm rotation schedule is defined (90-day default, or vendor-specific per the credential rotation guide)

Step 3 — Code review (for code changes)¶

For code touching auth or credential handling:

Review for plaintext credential patterns (grep per SOP-OPS-credential-management-v1.0 Section 6)
Review for injection risks in any user-controlled input paths
Confirm error handling does not expose credential values in logs or outputs
Confirm no sensitive data written to files accessible outside the intended scope

Step 4 — Vendor assessment¶

For new vendor relationships:

Confirm data residency (where does the vendor store data?)
Confirm vendor SOC 2 or equivalent — or document the gap if not available
Confirm data deletion policy if relationship ends
File assessment note to /Claude/operations/reports/security/vendor-assessment-{vendor}-{YYYY-MM-DD}.md
Forward to legal.exec for contract review if vendor will hold customer data

Step 5 — Review output¶

security.ops files a Security Review Report:

SECURITY REVIEW REPORT
──────────────────────────────
Subject: {integration / vendor / code change}
Date: {YYYY-MM-DD}
Reviewer: security.ops
Scope: {what was reviewed}
Credential handling: PASS | FAIL | N/A — {notes}
Minimum permission: PASS | FAIL | N/A — {notes}
Attack surface: {description} — ACCEPTABLE | NEEDS MITIGATION
Vendor assessment: PASS | FAIL | N/A — {notes}
Open risks: {any accepted risks with rationale}
Recommendation: APPROVE | APPROVE WITH CONDITIONS | REJECT
Conditions (if any):

Filed at /Claude/operations/reports/security/security-review-{subject}-{YYYY-MM-DD}.md.

4. Council Review for High-Sensitivity Security Decisions¶

Per SOP-EXEC-council-review-v1.0 Section 2A, security reviews involving: - New data residency decisions - Vendor access to customer data - Architectural changes to authentication

...are classified HIGH sensitivity and require council review using Ollama local only (no external APIs). security.ops invokes council review before making the recommendation in Step 5.

5. Approval Authority¶

Decision	Approval
New integration — low risk (read-only API, internal use only)	security.ops autonomous
New integration — medium risk (write access, external service)	COO approval
New vendor holding customer data	COO + legal.exec + CEO
Rejected integration despite exec pressure	security.ops files SEV2 Incident; COO makes final call

6. Escalation¶

Scenario	Action
Credential found in plaintext in code review	Immediate halt; SOP-OPS-credential-management-v1.0 Section 7 emergency rotation
Vendor cannot confirm data residency or deletion policy	Do not proceed; legal.exec consulted; COO decides
New integration expands agent access beyond R&R Matrix rights	chief.staff notified; COO approval required
Security review reveals a SEV1 condition	Immediate CEO notification per SOP-EXEC-escalation-incident-handling-v1.0

7. Quarterly Security Posture Review¶

security.ops runs a quarterly security posture review covering:

All active integrations — credential currency, access scope still appropriate
GitHub branch protection audit (per SOP-OPS-github-branch-protection-v1.0)
Credential rotation compliance (per SOP-OPS-credential-management-v1.0 Section 6)
Open security incidents — closed or actively remediated
New threat vectors relevant to the current tool stack

Quarterly report filed to /Claude/operations/reports/security/quarterly-posture-{YYYY-QN}.md and surfaced in CEO Daily Summary.

Change Log¶

Version	Date	Change
v1.0	2026-04-21	Initial draft — sop.manager. Establishes security review procedure for integrations, vendors, code changes, and agent capabilities.

Owner: security.ops Executive sponsor: coo Drafted by: sop.manager Status: Draft — pending COO approval Version: v1.0