OPS-SEC-001 — Establish private security/privacy reporting and rehearse incident response #112

Problem

The repository's security plan states that MPRC does not yet have a dedicated monitored security-reporting address. A member, volunteer, or researcher who finds exposed personal data, a compromised account, or another vulnerability needs a private path that does not place evidence in a public GitHub issue. Written procedures alone are not sufficient without named responders, working access, escalation ownership, and a rehearsal.

Atomic outcome

Establish a club-owned private security/privacy intake with primary and backup responders, then run one synthetic incident-response exercise that proves the handoff works. #104 owns the written architecture and officer playbooks; this issue configures ownership and provides operational evidence rather than rewriting them.

Owner actions

• Choose and provision a club-owned monitored address or approved private reporting channel, such as security@runmprc.com.
• Name a primary responder, backup responder, privacy escalation owner, platform owner, and payment/treasurer escalation where applicable.
• Require MFA and recovery access for the underlying mailbox/account; avoid a shared password.
• Define acknowledgement and escalation targets appropriate to the club, plus who can authorize containment, credential rotation, user notification, and outside advice.
• Privately inventory provider escalation contacts for Firebase/GCP, GitHub, Google Workspace/Sites, hosting/DNS, Stripe, email, Sentry, Strava, WhatsApp, and Instagram as applicable.

Engineering/documentation scope

• Point public vulnerability-reporting guidance to the private channel without publishing responder personal addresses or provider details.
• State clearly that public GitHub issues must not contain vulnerabilities, exploits, credentials, member/payment records, discount codes, or private URLs.
• Define a minimal private intake template: reporter contact, affected service, observation time, impact, synthetic reproduction, evidence location, and permission to follow up.
• Use ARCH-001 — Establish secure-commerce architecture and an atomic execution backlog #104's severity, containment, evidence-preservation, communication, recovery, and follow-up procedure as the authoritative playbook after it merges.
• Run a tabletop using synthetic scenarios only: one accidental member-data exposure and one privileged-account compromise.
• Record timestamps, roles reached, containment decision, gaps, corrective actions, and next drill date without copying sensitive evidence into GitHub.

Acceptance criteria

• The private reporting channel is club-owned, monitored by both primary and backup responders, protected by MFA/recovery controls, and tested from an unrelated account.
• Public site/repository guidance gives one clear private reporting path and warns against public disclosure of sensitive evidence.
• The escalation map identifies privacy, platform, payment, and provider responsibility without exposing private contact details publicly.
• Both synthetic scenarios are acknowledged, classified, escalated, and closed through the documented procedure.
• The exercise proves responders can reach the relevant owner and identify an authorized containment action without changing production.
• Gaps produce separate small tickets with owners and deadlines; no incident is marked resolved merely because a message was sent.
• Public evidence contains no real PII, secrets, tokens, private URLs, exploitable details, or security-contact personal data.

Dependencies and coordination

• Depends on ARCH-001 — Establish secure-commerce architecture and an atomic execution backlog #104/PR docs: add officer continuity and secure commerce guides #108 merging so its incident procedure is authoritative before repository/officer documentation is changed.
• Link findings to CI-001 — Establish trustworthy quality gates and protected deployment #105 for protected delivery/IAM gaps, MEMBERS-ACCESS-001 — Restrict the exposed Google Site and contain leaked discounts #80 for the exposed Google Site, STRAVA-001 — Harden and modernize the existing Strava OAuth connection #88 for Strava OAuth, and the relevant payment/provider ticket rather than broadening this issue.
• The approved data/vendor/contact inputs from DATA-001B — Inventory personal data and approve a minimization/retention matrix #110 should inform the privacy escalation map.
• Mailbox, MFA, provider, DNS, and production changes require a named authorized owner and private evidence.

Explicitly out of scope

• Publishing vulnerability details or private contact/provider inventories.
• Testing against real member data, exploiting production, downloading exposed records, or running a penetration test.
• Rotating credentials, disabling services, changing DNS/IAM, notifying users/regulators, or making legal determinations without explicit authority.
• Rewriting ARCH-001 — Establish secure-commerce architecture and an atomic execution backlog #104's security architecture or implementing monitoring, access control, backup, or data-deletion code.

Claim protocol

Creation is not a claim. Engineering/documentation work must be assigned and begin only after a timestamped CLAIMED by <canonical agent> at <UTC>; branch <branch> comment is posted and re-read. Earliest valid claim wins. External account and incident-authority actions remain owner-only.