AI Coding Risk Assessment: A Filled-In Template for Your Next Steering Committee

Most risk assessment templates you’ll find online are frameworks — methodology, category lists, scoring rubrics. They are not documents a steering committee can review. This one is the document. Pre-filled with the ten risks that recur across every organization rolling out AI coding tools, scored on a standard 5×5 inherent/residual matrix, with specific controls mapped to each row.

Copy it into Confluence, Notion, a Word doc — wherever your CISO’s audit trail lives. Adjust the numbers for your context. The structural work is done.

Cover Sheet

AI Coding Tools — Risk Assessment
Assessment period:   Q2 2026 (2026-04-01 to 2026-06-30)
Prepared by:         [Name], [Role]
Reviewed by:         [CISO / Head of AppSec]
Approved by:         [CTO / VP Engineering]
Next review date:    2026-07-01 (quarterly cadence)
Scope:               All engineering teams with approved AI coding tool access.
                     Excludes research teams under separate sandbox policy.
Tools in scope:      Claude Code, Cursor, GitHub Copilot, Codex
                     (add/remove as applicable)

Scoring Rubric

Likelihood (1–5)

• 1 — Rare: would require a specific, unusual failure chain
• 2 — Unlikely: possible but not observed in comparable orgs
• 3 — Possible: observed in at least one comparable org per year
• 4 — Likely: observed quarterly across the industry
• 5 — Almost certain: occurs in most deployments without mitigation

Impact (1–5)

• 1 — Minor: contained to one team, single-day resolution
• 2 — Moderate: multi-team, ≤1 week resolution, no customer-facing effect
• 3 — Significant: customer-facing incident, post-mortem required, no regulatory disclosure
• 4 — Major: customer data exposure OR regulatory disclosure OR >1 week production impact
• 5 — Severe: material financial loss, regulatory action, or public incident

Score = Likelihood × Impact. Bands: 1–6 Low, 7–12 Medium, 13–19 High, 20–25 Critical.

Risk Register

The numbers below are the defaults — calibrated for a mid-sized engineering org (100–500 engineers) six months into AI tooling rollout with basic controls (provenance trailers, SAST ruleset, code review for all merges). Adjust up if you have none of those; adjust down if you have comprehensive controls plus audit evidence.

R1 — Secret exposure via AI-generated code

Field	Value
Category	Security
Description	AI tool generates or developer inlines credential-shaped strings; commit lands in git and is later exfiltrated
Inherent L×I	5 × 4 = 20 (Critical)
Existing controls	Pre-commit hook (gitleaks/trufflehog), CI secret scan, rotation policy on detection
Residual L×I	2 × 4 = 8 (Medium)
Owner	AppSec Lead
Evidence	Monthly scan report, rotation ticket audit

R2 — SQL injection via string concatenation

Field	Value
Category	Security
Description	AI-generated DB access code uses concatenation/interpolation; injection discovered in production
Inherent L×I	4 × 5 = 20 (Critical)
Existing controls	SAST rule R-002 (block at merge), ORM-first policy, query review for any raw SQL
Residual L×I	2 × 5 = 10 (Medium)
Owner	AppSec Lead
Evidence	SAST finding counts, ORM-coverage metric

R3 — Authorization bypass in AI-generated endpoint

Field	Value
Category	Security
Description	New endpoint skips authz middleware or permissive default; attacker accesses protected resource
Inherent L×I	3 × 5 = 15 (High)
Existing controls	Authorization-required middleware at framework level (opt-out not opt-in), integration tests for every public route, CODEOWNERS gate on /auth paths
Residual L×I	2 × 5 = 10 (Medium)
Owner	Platform Eng Lead
Evidence	Route inventory + authz test coverage report

R4 — Vulnerable dependency introduced by AI recommendation

Field	Value
Category	Supply chain
Description	AI suggests package@version with known CVE or compromised maintainer; merges before scanner catches
Inherent L×I	4 × 4 = 16 (High)
Existing controls	OSV/Dependabot at PR time, SBOM generation, new-dep manual review for packages without prior internal use
Residual L×I	2 × 4 = 8 (Medium)
Owner	Platform Eng Lead
Evidence	Advisory ingestion latency, net-new dependency audit log

R5 — Undetected logic error in AI-generated business code

Field	Value
Category	Correctness
Description	Code compiles, passes basic tests, carries subtle defect (off-by-one, boundary, race); manifests in production
Inherent L×I	4 × 4 = 16 (High)
Existing controls	Gating decision tree routes high-blast-radius AI commits to flag lane, property-based testing on financial paths, mandatory second-reviewer for AI-Review-Confidence: low
Residual L×I	3 × 4 = 12 (Medium)
Owner	Engineering Managers (distributed)
Evidence	Defect density by provenance (quarterly)

R6 — Prompt or context leak containing sensitive internal data

Field	Value
Category	Data protection
Description	Developer pastes customer data, secrets, or IP into prompt; tool retains, trains on, or logs the content
Inherent L×I	4 × 4 = 16 (High)
Existing controls	Enterprise tier with zero-retention contractual commitment, DLP on clipboard-to-prompt vectors, allowlist of approved tools, mandatory training module
Residual L×I	2 × 4 = 8 (Medium)
Owner	Privacy Office
Evidence	DPA on file per tool, DLP trigger log, training completion rate

R7 — IP ownership ambiguity on AI-generated code

Field	Value
Category	Legal
Description	AI-generated code contains substring matching a copyleft/restricted-license source; downstream obligations attach
Inherent L×I	2 × 4 = 8 (Medium)
Existing controls	Tool vendor indemnification clauses, code similarity scan (BlackDuck/FOSSA/Socket), internal repository of AI-contaminated-path flagging
Residual L×I	1 × 4 = 4 (Low)
Owner	General Counsel + AppSec
Evidence	Vendor contract terms, scanner coverage

R8 — Compliance audit failure due to missing provenance

Field	Value
Category	Compliance
Description	Auditor (SOC 2, HIPAA, EU AI Act) asks “was this code AI-generated, who reviewed it” — org cannot answer for historical commits
Inherent L×I	4 × 3 = 12 (Medium)
Existing controls	Provenance trailers enforced at commit-msg hook and CI, retention in git matches regulatory period, quarterly trail-completeness audit
Residual L×I	2 × 3 = 6 (Low)
Owner	Compliance + AppSec
Evidence	Trailer coverage % per repo, audit readiness report

R9 — Developer skill atrophy / over-reliance

Field	Value
Category	Workforce
Description	Junior developers become unable to debug or reason about systems without AI assistance; knowledge gaps emerge at the senior level
Inherent L×I	3 × 3 = 9 (Medium)
Existing controls	Explicit curriculum for non-AI fundamentals in first 90 days, AI-off review sessions monthly, mentorship pairing
Residual L×I	2 × 3 = 6 (Low)
Owner	Engineering Manager Org
Evidence	Skills calibration review, mentor check-ins

R10 — Cost overrun from unbounded token consumption

Field	Value
Category	Financial
Description	Team usage exceeds forecast by >30% in a quarter; budget variance triggers finance review
Inherent L×I	4 × 2 = 8 (Medium)
Existing controls	Per-team quota, anomaly alerting on weekly burn rate, session-level analytics (debug widgets) to surface runaway processes
Residual L×I	2 × 2 = 4 (Low)
Owner	VP Eng + Finance partner
Evidence	Variance report, anomaly alert triage

Residual Risk Summary

Level	Count	Action
Critical (20–25)	0	N/A
High (13–19)	0	N/A
Medium (7–12)	5	Quarterly review, continued investment
Low (1–6)	5	Annual review, monitor only

Of ten categories, zero sit in High or Critical after controls. This is the target state. If your residual distribution shifts rows into High, the mitigation investments below become budget priorities for the next cycle.

Proposed Investments (next cycle)

Concrete, fundable items that would shift residuals further. Include only the ones that haven’t been funded yet; strike through or remove the rest:

1. Dedicated AppSec rule-tuning headcount (0.5 FTE). Quarterly review of the SAST ruleset, per-tool calibration. Expected residual shift: R2, R3, R4 each −1 likelihood.
2. Property-based testing in billing and auth paths. 2-engineer-month investment. Expected shift: R5 −1 likelihood on the paths that matter most.
3. DLP integration for prompt paste events. Vendor + integration cost. Expected shift: R6 −1 likelihood.
4. Trail-completeness dashboard exposed to compliance team. 1-engineer-week. Enables real-time evidence rather than quarterly audit. Expected shift: R8 residual impact −1 (faster recovery if a gap is found).

Total: ~$X (adjust for your cost base). ROI calculation tied to incident-avoidance estimate rather than direct savings — see the executive buy-in post for business-case framing.

Sign-off

Prepared by:  _______________________   Date: __________
Reviewed by:  _______________________   Date: __________
Approved by:  _______________________   Date: __________

Next review scheduled: ____________________

Using This Template

Three tips from orgs that have run this cadence for a year or more:

Don’t skip the inherent column. The temptation is to fill in only residual numbers because those are what you live with today. Inherent numbers are what justify the controls’ existence — if a control’s inherent-to-residual delta is zero, the control is decorative and should be cut. The column forces that accounting.

Score before reading your neighbors’ scores. When teams do this exercise together, scores converge toward whatever the first person said. Have each assessor write independently, then reconcile. Divergence is signal, not noise — the row where two assessors differ by two bands is the row most in need of discussion.

Review quarterly, not annually. Tool capability changes fast; control maturity changes fast; team composition changes fast. A 12-month-old assessment reflects a world that no longer exists. Quarterly keeps the numbers honest and the owners accountable.

For the governance policy language that sits on top of this assessment, see the governance framework. For the per-regulation compliance mapping that feeds row R8, see the compliance requirements guide.