Subscribe to unlock the Cyber Resilience Roadmap tracker.
| ★ | # | Task | Status | Weight | Assigned | Notes | Frameworks |
|---|
Environment snapshot — fill this in once per customer so you (or anyone on your team) can review it before a call instead of re-asking the same questions.
| Framework | Mapped | Compliant | Coverage |
|---|
| Task | Phase | Weight | Status |
|---|
CyRoadmap Risk Model: Risk Score = Likelihood × Impact (1-25). Risks are drawn from real Tracker gaps plus standard industry risks. Set the customer's Website/Industry above for the most accurate company profile.
| ID | Type | Category | Risk | Disposition | Impact | Likelihood | Score |
|---|
Track key governance meetings — e.g. Risk Assessment Review with Executive Leadership, ISO/IEC 27001 Management Review (Clause 9.3), or Internal Audit Results Review. Selecting a meeting type below auto-loads the standard agenda items for that meeting.
| Date | Type | Attendees | SOA | Actions |
|---|
A lightweight to-do list for governance work the GRC tracker doesn't cover on its own — internal audit prep, threat briefings, and similar recurring items.
| Category | Task | Due Date |
|---|
Log and track nonconformities per ISO/IEC 27001:2022 Clause 10.2 (and the equivalent ISO 9001 Clause 10.2): react to the nonconformity, evaluate the need for corrective action, implement it, review its effectiveness, and update the risk register if needed. Findings from internal/external audits, management review, incidents, or complaints all belong here.
| NC # | Identified | Source | Clause/Ctrl | Description | Severity | Owner | Due | Status | Actions |
|---|
Analyze and document the security impact of changes before implementation — hardware, software, configuration, network, or access changes that could affect the confidentiality, integrity, or availability of CUI or the environment. Maps to NIST SP 800-171 / CMMC 3.4.4 (Analyze the security impact of changes prior to implementation) and ISO/IEC 27001:2022 Annex A 8.32 (Change Management — safeguarding information assets when making changes to information processing systems and facilities).
| SIA # | Date | Type | Change Title | C | I | A | Risk | Status | Actions |
|---|
"Secure by design" isn't just a policy statement — it means checking for vulnerabilities in the pipeline itself, before code ships, and testing the running application the way an attacker would. These four free, no-license-required tools cover the places vulnerabilities most commonly hide: the code your team writes, the third-party dependencies it pulls in, secrets that get accidentally committed, and the live application itself. The first three run automatically in GitHub Actions on every push and pull request; the fourth scans your deployed app.
Static code analysis (SAST) — flags insecure patterns in the code your team writes.
Dependency scanning (SCA) — flags known CVEs in third-party packages and opens patch PRs. Built into GitHub, free on every plan.
Secret scanning — catches API keys, passwords, and tokens accidentally committed to the repo, including in old commits.
Dynamic application testing (DAST) — scans the deployed, running app from the outside for issues that only show up at runtime. Needs a staging URL, not just a repo.
The guide includes copy-paste-ready GitHub Actions workflow files and config for all four tools, plus notes on what each flag does, where the free tier's limits are, and why ZAP needs a deployed environment rather than just the repo.
The IT Director Report has moved to the Reporting tab. The Risk Assessment now lives in its own tab.
Tip: Use the ★ column in the Tracker tab to flag tasks for the board deck's detail slides.