# Product Security Operating Processes — Director Audit Checklist

> **Audience:** Product Security Director, Product Security Manager, transformation lead\
> **Use this page when:** you join a new company and need to quickly assess whether the company has the minimum operating processes needed for a functioning Product Security program.

## Why process matters here

A Product Security program fails less often because of a missing scanner than because of:

* unclear ownership;
* inconsistent release gates;
* ad hoc access decisions;
* weak secrets handling;
* missing exception governance;
* no evidence path;
* remediation work that has no agreed SLA or escalation path.

This page excludes classical enterprise-perimeter topics such as corporate SIEM tuning, desktop AV, or office-network firewall administration unless they directly touch product delivery.

## The director’s first principle

A mature company does **not** need 100 security processes.\
It needs a small set of **reliable, repeatable, auditable workflows** tied to product build, deploy, operate, and improve loops.

## Core Product Security operating processes

### 1) Access provisioning, modification, and removal

**Why it matters:** privileged access is one of the highest leverage failure modes across source code, CI/CD, cloud, Kubernetes, secrets, and production data.

**Minimum expectations**

* documented request and approval path;
* role-based access mapping for engineering, platform, and security admins;
* time-bound elevation for high-privilege actions;
* periodic review of privileged groups;
* offboarding revokes access across code, CI/CD, cloud, and secrets stores.

**Typical evidence**

* access request tickets;
* approval records;
* privileged group membership export;
* quarterly access-review sign-off;
* deprovisioning checklist.

### 2) Repository onboarding and source-control governance

**Why it matters:** this is where unsafe defaults spread at scale.

**Minimum expectations**

* repo template or baseline for branch protection;
* required review for protected branches;
* CODEOWNERS or equivalent ownership model;
* security contact / SECURITY.md pattern;
* secret scanning and dependency update baseline.

**Typical evidence**

* org-level repo settings;
* protected branch policy screenshots / exports;
* sample CODEOWNERS files;
* exception list for nonconforming repos.

### 3) Design review and threat-modeling intake

**Why it matters:** if critical changes enter implementation without security design review, defects are discovered too late.

**Minimum expectations**

* explicit criteria for “what must be reviewed”;
* lightweight intake form;
* threat-model requirement for tier-0 / tier-1 systems or sensitive changes;
* architectural decision records for compensating controls and trade-offs;
* decision ownership and due dates.

**Typical evidence**

* threat model templates;
* completed review records;
* risk decisions and sign-offs;
* % critical systems with current threat model.

### 4) Secure build and deployment control

**Why it matters:** this is the product-security control plane in motion.

**Minimum expectations**

* runner isolation and trust boundaries;
* controlled use of secrets in CI/CD;
* release approval path for high-risk systems;
* artifact provenance/signing expectations where justified;
* deployment approval evidence retained for major releases.

**Typical evidence**

* CI/CD policy config;
* runner inventory and isolation notes;
* release sign-off checklist;
* provenance or attestation sample;
* production deployment approval records.

### 5) Vulnerability intake, triage, remediation, and exception handling

**Why it matters:** detection without triage discipline is theater.

**Minimum expectations**

* one intake path for findings from scanners, researchers, pentests, and internal reviews;
* severity plus context model;
* remediation SLA by severity/system criticality;
* exception/risk acceptance workflow;
* escalation path for overdue critical issues.

**Typical evidence**

* vuln queue exports;
* SLA definitions;
* sample triage notes;
* exception log;
* aging dashboard or workbook.

### 6) Secrets management lifecycle

**Why it matters:** secrets are often the shortest path from design flaw to production impact.

**Minimum expectations**

* no long-lived secrets in repos or CI variables without justification;
* issuance path for secrets and service identities;
* rotation expectations;
* break-glass handling;
* decommissioning path when systems retire.

**Typical evidence**

* secrets inventory or registry;
* rotation job or runbook;
* vault/KMS policy examples;
* emergency-access record.

### 7) Key management and cryptographic governance

**Why it matters:** crypto failures often come from lifecycle failure, not algorithm theory.

**Minimum expectations**

* ownership of KMS / HSM / signing keys;
* separation between KEK/DEK or signing vs encryption keys;
* rotation and revocation/retirement rules;
* envelope encryption pattern for sensitive data;
* defined approval path for new cryptographic usage.

**Typical evidence**

* KMS key inventory;
* key policy examples;
* rotation logs;
* signing workflow docs.

### 8) Cloud account / subscription / project baseline governance

**Why it matters:** account-level sprawl becomes blast-radius sprawl.

**Minimum expectations**

* tiering of accounts/subscriptions/projects;
* baseline controls for logging, identity, break-glass, encryption, and guardrails;
* high-risk change review for public exposure changes;
* posture findings ownership;
* exception handling.

**Typical evidence**

* landing-zone baseline;
* cloud policy-as-code samples;
* account inventory;
* posture dashboard or exported findings.

### 9) Kubernetes / platform onboarding and cluster policy governance

**Why it matters:** cluster security decays quickly without baseline enforcement.

**Minimum expectations**

* cluster onboarding checklist;
* namespace / environment segmentation rules;
* RBAC model;
* pod hardening and admission policy baseline;
* exception path for privileged workloads.

**Typical evidence**

* cluster baseline checklist;
* Kyverno/Gatekeeper/PSA policy set;
* sample namespace policy;
* RBAC review records.

### 10) Logging, telemetry, evidence retention, and immutable records

**Why it matters:** without reliable records, you cannot prove control operation or reconstruct incidents.

**Minimum expectations**

* logs for privileged actions and release approvals;
* retention policy;
* immutable or tamper-resistant archive for critical evidence;
* ownership of retrieval and review;
* alignment with incident and audit needs.

**Typical evidence**

* logging standard;
* retention settings;
* sample immutable bucket / archive config;
* privileged-event query examples.

### 11) Backup, restore, and recovery assurance for product systems

**Why it matters:** backups are only security controls if restore works under pressure.

**Minimum expectations**

* backup ownership;
* restore test cadence;
* encryption for backups and key handling;
* immutability where justified;
* explicit recovery objectives for critical systems.

**Typical evidence**

* backup schedule;
* restore test report;
* storage encryption setting;
* exception or gap register.

### 12) Dependency and third-party component governance

**Why it matters:** product risk includes what you import, not only what you write.

**Minimum expectations**

* dependency update cadence;
* approval model for new sensitive dependencies;
* deprecated/unmaintained component tracking;
* supplier / vendor SDL expectations where applicable;
* OpenSSF / provenance / signature considerations for high-risk components.

**Typical evidence**

* dependency policy;
* update-bot config;
* allow/deny list;
* third-party review record.

### 13) Independent assessment request process

**Why it matters:** pentests and external reviews must not be random acts.

**Minimum expectations**

* trigger criteria for external review;
* intake and scoping workflow;
* engineering owner for remediation;
* retest criteria;
* customer-facing summary if needed.

**Typical evidence**

* assessment request form;
* signed scope;
* remediation plan;
* retest report.

### 14) Security release governance

**Why it matters:** if no one can answer whether a risky release is actually ready, the system is immature.

**Minimum expectations**

* defined security sign-off criteria;
* acceptance criteria by release tier;
* emergency-release path;
* escalation path when gates are not met;
* retained evidence for critical releases.

**Typical evidence**

* release sign-off template;
* sample approved release packet;
* emergency-release exception records.

### 15) Lessons-learned to backlog feedback loop

**Why it matters:** mature programs convert incidents, pentests, and escapes into default improvements.

**Minimum expectations**

* post-incident review outputs mapped to backlog;
* recurring issue pattern tracking;
* standard owner for preventive platform improvements;
* quarterly review of repeated failure modes.

**Typical evidence**

* postmortem actions;
* prevention backlog;
* theme analysis of repeated findings.

## Build order: what to stand up first

If you are walking into a chaotic company, implement in this order:

1. access provisioning and periodic review
2. repository governance baseline
3. vulnerability intake / triage / exception workflow
4. design-review and threat-model intake
5. release governance and deployment approval evidence
6. secrets lifecycle
7. cloud / Kubernetes baseline governance
8. logging / evidence retention
9. dependency and supplier governance
10. backup / restore assurance
11. independent assessment workflow
12. lessons-learned feedback loop

## A fast first-30-days audit table

| Process              | Why it matters                         | Quick test                         | Bad smell                                |
| -------------------- | -------------------------------------- | ---------------------------------- | ---------------------------------------- |
| access management    | prevents uncontrolled privilege spread | ask for list of admins by system   | nobody can produce one quickly           |
| repo governance      | sets safe defaults for all changes     | sample 10 critical repos           | inconsistent protections                 |
| threat modeling      | catches risk before code hardens       | ask for recent examples            | only slideware or no artifacts           |
| vuln triage          | turns findings into action             | inspect aging and ownership        | “the scanner knows, ask it”              |
| release governance   | links security to change approval      | review 3 critical releases         | no evidence packet exists                |
| secrets lifecycle    | prevents credential sprawl             | inspect one end-to-end secret path | secrets live forever                     |
| cloud / k8s baseline | controls blast radius                  | inspect baseline and exception log | cluster/account-by-account improvisation |
| immutable records    | protects evidence                      | ask where privileged logs live     | logs editable by same admins             |
| backups and restore  | preserves recovery capability          | ask for last restore test          | backup exists, restore unknown           |

## What a mature company usually has that an immature one lacks

* standard intake paths instead of ad hoc Slack asks;
* named owners for each decision type;
* documented exceptions with expiry;
* repeatable evidence rather than screenshots assembled under pressure;
* backlog feedback loops from incidents and assessments;
* enough process to be reliable, not so much process that delivery stops.

## Suggested cross-links

* [🗂️ Product Security Policy Library and DOCX Starter Pack](/metrics-audit-risk-evidence-and-compliance/index/product-security-policy-library-and-docx-templates.md)
* [🧰 Mature Product Security Workflows, Stage Gates, and Operating Loops](/metrics-audit-risk-evidence-and-compliance/index/mature-product-security-workflows-stage-gates-and-operating-loops.md)
* [🧾 SOX 404-Style ITGC for Product Security, DevSecOps, Cloud, and Kubernetes](/metrics-audit-risk-evidence-and-compliance/index-1/sox404-style-itgc-for-product-security-devsecops-cloud-and-kubernetes.md)
* [🚦 Release Governance — Security Sign-Off, Quality Gates, Acceptance Criteria, and Escalation](/devsecops-cicd-and-supply-chain/index-1/release-governance-security-signoff-quality-gates-acceptance-criteria-and-escalation.md)
* [🛡️ Secure Build Factory / Artifact Signing / Deployment Approval Evidence Pack](/devsecops-cicd-and-supply-chain/index-1/secure-build-factory-artifact-signing-and-deployment-approval-evidence-pack.md)

## References

* NIST SSDF — <https://csrc.nist.gov/pubs/sp/800/218/final>
* OWASP SAMM — <https://owasp.org/www-project-samm/>
* OpenSSF Scorecard — <https://www.scorecard.dev/>
* SLSA — <https://slsa.dev/>

***

*Author attribution: Ivan Piskunov, 2026 – Educational and defensive-engineering use.*


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.product-security.expert/strategy-governance-and-leadership/index/product-security-operating-processes-director-audit-checklist.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.