Back to governance document pack

Governance document

Evidence Calendar

Monthly, quarterly, annual, and per-event evidence collection schedule.

Download PDF

CIC Evidence Calendar

Last updated: 01/15/2024

Purpose

This calendar defines recurring evidence CIC should collect to prove policies and controls are operationalized.

Monthly Evidence

EvidenceOwnerNotes
Evidence calendar reviewGovernance adminConfirm missing or overdue evidence.
Open high and critical risk reviewSecurity ownerConfirm treatment status.
Open incident and remediation reviewSecurity ownerConfirm closure progress.
Vulnerability remediation reviewEngineering ownerConfirm aging and priority.
Production deployment sample reviewEngineering ownerConfirm PR, tests, and deployment traceability.
Financial exception reviewFinance ownerReview duplicate, missing, stale, or failed financial postings.
Support verification sample reviewSupport ownerConfirm sensitive support actions were verified.
Public profile report reviewOperations ownerConfirm profile reports, visibility complaints, and content issues were dispositioned.
Support queue aging reviewSupport ownerConfirm old tickets, escalations, and user feedback are being handled.
PFS journal and metadata sample reviewFinance ownerConfirm posted journals, metadata creation, and report extraction are complete and traceable.

Quarterly Evidence

EvidenceOwnerNotes
Privileged access reviewGovernance adminReview cloud, repos, production, admin tools, support tools.
Financial operations access reviewFinance ownerReview wallet, ledger, transaction, and admin permissions.
Security risk register reviewSecurity ownerUpdate ratings, owners, and treatment plans.
Exception register reviewGovernance adminExpire, renew, or close exceptions.
Critical vendor watch reviewVendor ownerCheck material changes, incidents, and renewals.
Public profile and content report reviewOperations ownerConfirm profile/content reports are dispositioned.

Annual Evidence

EvidenceOwnerNotes
Policy reviewGovernance adminReview all approved policies.
Enterprise risk assessmentExecutive ownerBusiness, operations, security, vendor, financial, compliance.
Security risk assessmentSecurity ownerProduct, infrastructure, data, access, vendor, SDLC.
Vendor reassessmentVendor ownerCritical vendors.
Incident response tabletopSecurity ownerInclude security and customer support scenarios.
Disaster recovery testOperations ownerValidate recovery for critical systems.
Standard access reviewGovernance adminNon-privileged access.
Internal control assessmentGovernance adminEvaluate design and operation of core controls.
Security awareness acknowledgementPeople or Operations ownerPersonnel with system access.
Cookie and tracking technology reviewPrivacy ownerConfirm cookie register and public policy remain accurate.
Public policy reviewPrivacy or Legal ownerReview Privacy Policy, Terms, Cookie Policy, and DPA summary.
Business impact analysis refreshOperations ownerConfirm critical workflows, RTO, RPO, and workarounds remain accurate.
Personnel policy acknowledgementPeople or Operations ownerConfirm personnel with access have acknowledged current policies.
Support call-back and screen-share control reviewSupport ownerValidate code exchange, consent, file request, and rating controls.

Per-Event Evidence

EventEvidence
New vendorVendor security review, contract review, risk tier.
New policyIntake, draft, review comments, approval, publication.
Policy exceptionRisk assessment, approval, expiry date, compensating controls.
Security incidentIncident record, timeline, root cause, remediation, postmortem.
Production releasePR, review, tests, deployment record.
Privileged access requestRequest, approval, grant date, removal date if temporary.
User terminationDeprovisioning evidence.
Material architecture changeRisk review and security review.
Financial repair or migrationApproval, dry run where applicable, before and after counts, affected IDs, reconciliation result.
New public data fieldPrivacy review, classification, public display approval, retention mapping.
New support file request typePurpose, data classification, retention, access limitation.
New AI or automation toolTool review, data classification boundary, approved use cases.
External audit or due diligence requestRequest scope, evidence package, response owner, final submission record.
User data rights requestVerification, systems searched, action taken, response date.

Evidence Quality Standard

Evidence should identify:

  • What control operated.
  • Who performed it.
  • When it was performed.
  • What period it covered.
  • What system or process was covered.
  • What result was observed.
  • What exceptions were found.
  • What remediation was opened.

Evidence Storage Standard

Evidence should be stored in a controlled repository or system with clear naming, date, owner, control ID, and review period. Evidence should not be casually stored in personal drives or chat threads unless copied into the official evidence location.

Evidence Naming Standard

Recommended evidence naming:

`YYYY-MM-DD_CONTROLID_PERIOD_OWNER_SHORT-DESCRIPTION`

Examples:

  • `2026-06-30_CIC-AC-002_Q2_GOV_PRIVILEGED-ACCESS-REVIEW`
  • `2026-06-30_CIC-FIN-003_JUNE_FIN_WALLET-RECONCILIATION`
  • `2026-06-30_CIC-SUP-001_JUNE_SUPPORT_VERIFICATION-SAMPLE`

Evidence Acceptance Criteria

Evidence should be rejected or returned for correction when:

  • It does not show the control period.
  • It does not identify the reviewer or performer.
  • It only states that a control happened without showing support.
  • It is a screenshot with no context, owner, or date.
  • It omits exceptions or remediation.
  • It includes sensitive data that should have been redacted.

Evidence Repository Index

CIC should maintain an index that maps evidence to control ID, period, owner, storage location, reviewer, exceptions, and remediation record. The index should be reviewed monthly during program build-out.