Plan 6 — Spec §14 stakeholder decision log

Source: 2026-05-08-azure-devops-aws-eks-cicd-design.md §14 (Open questions for stakeholders). 5 open questions, 0 decided as of 2026-05-17 (Plan 6 baseline B-24 FAIL).

Purpose: Drive each of the 5 open questions to a documented decision with owner, decision-by-date, and recorded rationale. Each decision MUST be signed off before its blocking gate fires (see "Plan 6 dependency" column).

Status legend:

• OPEN — no decision yet
• RECOMMENDED — engineering's proposal awaiting stakeholder confirmation
• DECIDED — signed off; recorded in compliance/cic-sign-offs.md
• DEFERRED — explicitly punted past Plan 6 (must specify when revisited)

---

Q1 — Reserved Instance commitment timing

Question: Buy RIs at T+90 days (post burn-in) or sooner? Earlier = more savings, later = preserves sizing flexibility.

Status: RECOMMENDED

Engineering proposal: Hybrid — buy 1-year No-Upfront RIs at T+30 days for the BASELINE-stable workload (EKS control plane, prod RDS r6g.large primary, prod ElastiCache r6g.large primary). Re-evaluate ALL other sizing at T+90 days after burn-in surfaces actual traffic patterns; commit to incremental RIs then.

Rationale:

• Current prod monthly run-rate ≈ $1390 (data layer ~$960 + cluster ~$430).
• 1-year No-Upfront RI savings: ~30% on RDS, ~28% on EC2/EKS = ~$400/mo savings.
• Standing up to 100% on-demand for 90 days = ~$1200 lost vs hybrid.
• BASELINE workload (control plane + prod primary DB) WILL be needed regardless of burn-in outcomes — no flexibility cost.
• The rest (replicas, HPA-scaled compute, OpenSearch) genuinely needs burn-in data before commit.
• No-Upfront option keeps cash flow stable; can be cancelled at 1-yr.

Owner: CFO + SRE Lead

Decision-by-date: 2026-07-15 (T+60 days from prod cutover, assuming cutover ≈ 2026-06-01)

Plan 6 dependency: None (cost optimization, not launch blocker)

Sign-off captured at: compliance/cic-sign-offs.md once decided.

---

Q2 — GuardDuty + Security Hub on non-prod

Question: Keep on all 4 envs ($10/env GuardDuty + ~free Security Hub above some bps) for parity, or trim test/qa to save ~$20/mo?

Status: RECOMMENDED

Engineering proposal: Keep on all 4 envs. No trim.

Rationale:

• $20/mo savings is negligible vs platform total spend (~$2890/mo).
• Parity means non-prod environments surface the same class of finding prod would — leaked IAM role pattern, misconfigured S3 bucket, etc.
• Many security findings DON'T reproduce on prod-sized data but DO on test (engineer's misconfigured Terraform sandbox lands first on test).
• Eliminating non-prod GuardDuty means losing the early-warning signal for "we are about to ship a vulnerable change to prod."
• Plan 0 baseline already provisions GuardDuty per env — the per-env CMK
  • IRSA wiring is in place. Trimming requires Terraform changes + future re-enable costs same engineering hours.

Owner: CISO + SRE Lead

Decision-by-date: 2026-06-01 (before Plan 6 baseline B-11 re-run on operator shell, which validates GuardDuty across 5 accounts).

Plan 6 dependency: B-11 (multi-account GuardDuty walk). If decided "trim non-prod" before B-11 re-run, the verify needs to be relaxed to prod-only.

---

Q3 — Slack channel scheme for deploys

Question: #deploys-{env} per env (4 channels), or single #deploys with env tags?

Status: RECOMMENDED

Engineering proposal: Per-env channels. #deploys-test, #deploys-qa, #deploys-staging, #deploys-prod. (Note: per Plan 3 FU-25, Slack itself is being migrated to Microsoft Teams; the same per-env channel decision applies to Teams as well.)

Rationale:

• Spec §14 already states "Prefer per-env for noise control" — this proposal codifies that preference.
• During incident response, single channel becomes noisy (test+qa deploys fire every 10-15 min at peak; prod incidents need clean signal).
• Per-env channels also enable per-env access control: prod channel can be ADMIN+SRE only; test channel can be public to all of engineering.
• No marginal cost (Slack/Teams charges per user, not per channel).
• Pager routing is per-channel, so #deploys-prod auto-routes to the on-call SRE while #deploys-test stays passive.

Owner: SRE Lead + Eng Lead

Decision-by-date: 2026-05-30 (low stakes; just align on convention so ArgoCD notification annotations + Azure Pipelines slack-notify.yml step emit to the right channel from day 1).

Plan 6 dependency: None (operational hygiene, not launch blocker).

---

Q4 — On-call rotation for prod approvals

Question: Does the 2-of-N prod approval gate have ≥3 named approvers today? If not, we need to set one up before prod cutover.

Status: OPEN (no current decision; engineering proposal is BLOCKER status)

Engineering proposal: BLOCKER — set up before first-property onboarding. The 2-of-N gate requires a minimum of 3 named approvers in the keynova-prod Azure DevOps Environment. Today we have:

Role	Named human	Backup
Release Manager	<UNFILLED>	<UNFILLED>
Eng Lead	ajay.navgale@centralogic.net	<UNFILLED>
On-call SRE	<UNFILLED>	<UNFILLED>

Proposed structure:

• 3 named human approvers in Azure DevOps Environment for prod
• PagerDuty schedule with weekly rotation (Mon 09:00 IST handoff)
• Documented in monitoring/runbooks/on-call-rotation.md (TO BE AUTHORED — separate ticket)
• Pager escalates from primary → backup → eng-lead after 15 min

Rationale:

• Plan 4 Task 24 (prod demo seed) explicitly requires 2-of-N approval
• Plan 5 cutover-day requires operator + approver (separation of duties)
• Plan 6 first-property onboarding will produce frequent prod changes during onboarding ramp — without rotation, a single human becomes the bottleneck

Owner: VP Eng + SRE Lead

Decision-by-date: 2026-06-15 (Plan 6 first-property pre-flight gate)

Plan 6 dependency: HARD BLOCKER for first-property onboarding.

---

Q5 — Backup retention beyond AWS Backup defaults

Question: Current policy 7-day non-prod, 30-day prod. Compliance (DPDPA / SOC 2) may push for longer audit log retention. Confirm before Phase 0 (prod launch).

Status: RECOMMENDED

Engineering proposal: No change to app data retention. Audit logs already satisfy SOC 2 via separate retention.

Layer	Current retention	SOC 2 / DPDPA requirement	Conflict?
App data (RDS) on prod	30 days	None for app data	No
App data (RDS) on non-prod	7 days	None for app data	No
CloudTrail audit logs	7 years (S3 Object Lock COMPLIANCE)	SOC 2 ≥1 year	No (exceeds)
K8s audit logs (CloudWatch)	90 days	SOC 2 ≥90 days	No (matches)
ALB access logs	90 days (S3 lifecycle)	SOC 2 ≥90 days	No (matches)
Application logs (Loki S3)	30/90 days (governance Object Lock)	No specific req	No
DPDPA right-to-erasure (guest PII)	Erase ≤30 days after request	DPDPA Article 11(1)	App data 30-day retention satisfies

Rationale:

• DPDPA Article 11(1) right-to-erasure CONFLICTS with extended app data retention. Keeping prod RDS backups at 30 days (not 90+) means a guest who exercises right-to-erasure has their data fully purged within 30 days of the erasure request — the JIT BackupVaultEmergencyDelete pattern from Plan 2 CIC-5 handles the case where erasure is requested before the natural 30-day expiry.
• SOC 2 audit retention is about LOGS (who-did-what), not app data. Those are already 7y/90d via separate buckets.
• Longer app data retention = larger DPDPA blast radius for each erasure request. Keep tight.

Owner: Legal/DPO + CISO + SRE Lead

Decision-by-date: 2026-06-15 (Plan 6 first-property pre-flight gate)

Plan 6 dependency: HARD BLOCKER if compliance disagrees with the recommendation — would require Terraform changes to backup plans + re-applying across 4 envs.

---

Closure procedure

For each question above, the named owner:

1. Reviews the engineering proposal.
2. Either accepts (→ DECIDED) or proposes an alternative (→ updates this doc's "Engineering proposal" section + re-circulates).
3. Once signed off, appends a row to compliance/cic-sign-offs.md under the new "Plan 6 Spec §14 Decisions" section with the decision date + approver signature method (Jira comment / email / DocuSign).
4. Updates this doc's status from RECOMMENDED to DECIDED.

When all 5 are DECIDED, baseline-checklist B-24 re-runs PASS.

Compliance mapping

Decision	Framework / control
Q1 RI commitment	None (cost-only)
Q2 GuardDuty non-prod	ISO 27001 A.12.4 (Logging + monitoring)
Q3 Slack scheme	None (operational)
Q4 On-call rotation	SOC 2 CC 7.4 (Incident response)
Q5 Backup retention	DPDPA Article 11(1) + SOC 2 PI 1.1 + ISO 27001 A.18