Competition Strategy 12
Strategy Checklist
Bring the entire Competition Strategy section together into one practical workflow for authorized CyberPatriot practice.
This checklist is not a substitute for understanding the image. It is a reminder of the reasoning habits that should guide the team from the first minute to the final review.
Lesson Snapshot
Learning objectives
What this final strategy lesson should help you do
Combine the full competition-strategy section into one repeatable workflow that can be used during authorized practice rounds.
Use the scenario, baseline, prioritization, evidence, communication, documentation, and verification habits together rather than as isolated ideas.
Recognize which checklist items belong at the beginning, middle, and end of a round.
Separate high-confidence work from investigation, coordination, and revisit tasks.
Protect required services, users, and forensic evidence while hardening the environment.
Finish the round in a verified, scenario-compliant, known-good state.
Core principle
Use the checklist to remember the process, not replace thinking
Every competition image is different. The checklist should help you remember what to consider, while the scenario and evidence determine what you actually change.
Safety boundary
Train the reasoning, not live-round answers
Use this material in authorized training environments and fictional practice scenarios. The goal is to build defensive judgment and repeatable habits rather than provide answers to a live competition image.
Opening phase
Before broad hardening begins
Read the full scenario and ReadMe before broad changes.
Identify the machine's role and required purpose.
List authorized users.
List authorized administrators separately.
Record required services, applications, roles, and network functions.
Record restrictions, exceptions, and must-not-change items.
Read every forensic question early.
Identify evidence-rich areas that should be preserved.
Assign team roles and system ownership.
Create a shared task board.
Establish a quick baseline of users, security tools, services, updates, and networking.
Separate confirmed facts from unknowns and assumptions.
Task board
Keep every finding in the right work category
Do Now
High-confidence, useful work with clear evidence and manageable risk.
Investigate
Potentially important findings that still need stronger evidence or context.
Coordinate
High-impact changes that may affect networking, authentication, permissions, services, evidence, or another teammate.
Revisit
Blocked, low-confidence, or time-consuming tasks that should remain visible without consuming the whole round.
Done / Verify
Completed actions that still need confirmation, documentation, or functional testing.
Before every major change
Eight questions before you act
What specific problem am I trying to solve?
What evidence proves this is actually a problem?
Does the scenario require the affected user, service, software, or capability?
What is the least disruptive change that addresses the problem?
What could break if my assumption is wrong?
Does this action affect forensic evidence?
Who else on the team needs to know?
How will I verify the result afterward?
Evidence check
Know what supports your decision
Scenario evidence
What do the competition instructions explicitly require, allow, or prohibit?
System evidence
What does the current machine state actually show through users, settings, services, files, logs, processes, or configuration?
Policy evidence
What secure-state expectation or defensive policy helps define the desired configuration?
Forensic evidence
What artifacts, timestamps, logs, or metadata support the conclusion?
Communication
Keep team ownership and risk visible
Every active task has one clear owner.
High-impact changes are announced before they happen.
Important results are reported after verification.
Unresolved work stays visible on the shared board.
Forensic risks are communicated before evidence-changing actions.
Handoffs include the problem, evidence, attempts, current state, and next question.
The coordinator watches for duplicate work and missing ownership.
Team updates stay short and useful.
Documentation
Track what matters without slowing the team
Record the system and area being changed.
Record the observed state before a major change.
Record the reason for the change.
Record the command, setting, or action used when it matters.
Record unexpected errors or side effects.
Record the verification result.
Label assumptions and unknowns clearly.
Keep unresolved follow-up visible.
Do not store passwords, private keys, or sensitive credentials in shared notes.
Required services
Preserve the mission while reducing risk
Confirm the service, application, or role is actually required.
Identify who or what depends on it.
Identify ports, protocols, interfaces, and network exposure.
Identify authentication and privilege requirements.
Identify files, shares, directories, or other dependencies.
State the exact security problem.
Choose the least disruptive hardening action.
Verify required access still works.
Verify unnecessary exposure is reduced.
Check logs and dependent systems for errors.
Forensics
Protect evidence before cleanup
Read each forensic question before broad cleanup.
Identify the exact fact the question asks for.
Map the question to likely evidence sources.
Preserve relevant files, logs, accounts, processes, timestamps, and configuration artifacts.
Separate fact, inference, unknown, and assumption.
Cross-check important conclusions when possible.
Document the evidence supporting each answer.
Move time-consuming forensic work to Revisit when needed.
Return during final review and confirm every answer directly matches the question.
When you get stuck
Recover control instead of repeating failed attempts
Pause after repeated failure instead of stacking more changes.
Restate the expected end state.
Write the exact symptom or error.
Review what has already changed.
Identify the next unknown.
Check dependencies, logs, permissions, networking, and authentication as appropriate.
Ask a teammate for a second opinion when it could save time or reduce risk.
Move the task to Revisit when the time cost exceeds the current value.
Record enough context to return later without starting over.
Verification
Four layers before a task is truly complete
Configuration
Did the setting, policy, permission, service, account, or rule actually change to the intended state?
Security
Did the original weakness or unnecessary exposure actually decrease?
Functionality
Do required users, services, applications, roles, and network paths still work?
Team awareness
Was the result recorded and communicated if it affects other work?
Final review
Finish in a known-good state
Re-read the scenario and ReadMe.
Confirm authorized users and administrators.
Confirm required services, software, roles, and network functions.
Confirm restrictions and exceptions are still satisfied.
Review all Done / Verify tasks.
Review unresolved high-value tasks.
Re-check networking and firewall changes.
Re-check authentication and permission changes.
Re-test required services and user workflows.
Review every forensic answer and supporting evidence.
Look for temporary workarounds or incomplete changes.
Avoid broad new changes that cannot be verified.
Document unresolved risks.
Finish in a known-good, verified state whenever possible.
Failure patterns
Six habits to actively avoid
Checklist without context
Applying generic hardening steps without reading the scenario can break required functionality.
Unknown equals malicious
Unfamiliar users, services, or software should be investigated before destructive action.
Too much silent work
High-impact changes made without communication create conflicts and hidden dependencies.
No verification
A successful command or saved setting does not prove the task is complete.
One problem consumes the round
Difficult tasks should move to Revisit when they stop producing useful progress.
Last-minute guessing
Time pressure should increase caution, not reduce the evidence threshold.
Full practice sequence
The complete competition strategy in seven steps
Read and map
Turn the scenario into a concise list of requirements, restrictions, authorized users, required services, and forensic targets.
Baseline
Build a quick picture of users, privileges, security controls, services, software, updates, and networking.
Prioritize
Sort findings into Do Now, Investigate, Coordinate, Revisit, and Done / Verify.
Act with evidence
Make the least disruptive justified change and protect required functionality.
Verify
Check configuration, security improvement, functionality, and team impact.
Document and communicate
Keep major changes, evidence, results, and unresolved items visible.
Review
Re-read requirements, revisit high-value tasks, verify forensic answers, and finish in known-good state.
Reflection
Check that the strategy makes sense as one system
Question 1
Why should the scenario be treated as a technical constraint rather than background information?
Question 2
What is the difference between a Do Now task and an Investigate task?
Question 3
Why should high-impact changes have a stronger evidence and communication requirement?
Question 4
How does documentation improve troubleshooting and team coordination?
Question 5
Why is protecting required services different from leaving them unchanged?
Question 6
What should happen when a task becomes a time trap?
Question 7
Why should verification include both security and functionality?
Question 8
What changes in your decision-making as the round approaches the final minutes?
Strategy section complete
You now have the full competition-strategy workflow
Review the twelve strategy lessons for consistency, accuracy, and layout using the Previous / Next navigation. After the review is complete, the Strategy hub can be fully connected before moving on to the next CyberPatriot training area.