Skip to main content

Session 7 — Design and evaluate a security plan

Previous session · Course index · Next session

Time: 60 minutes. Goal: Produce a practical plan and justify choices using the scenario.

TaskMinutes
Recall controls and risks5
Read the planning notes10
Core video and question5
Write your plan30
Self-review and improvement10

1. Start with what must work

The Harbour School Robotics Club has 80 members, two treasurers and a teacher supervisor. It stores contact details and payment records. A shared laptop sometimes goes home. The club has a small budget and limited IT support. It must be able to recover records within one school day.

The original arrangement has one shared password, editing access for all members and no separate backup. Your plan should improve this arrangement while keeping administration manageable.

Write down assets and necessary activities before choosing technology. Members need their own payment status; they do not need everyone's contact details. Treasurers need to update payments; they do not automatically need to manage system accounts. The supervisor needs oversight and an agreed route to school IT.

Read the diagram: A plan is a reasoned cycle. Buying a security product is not the starting point, and writing a plan is not the end of the process.

A useful sentence pattern is:

Because [specific weakness] could allow [specific harm], use [control]. It works by [mechanism], protecting [security goal]. However, [limitation], so [complementary measure or justified trade-off].

Worked paragraph: Because the laptop leaves school, loss could expose members' contact details. Full-disk encryption protects stored information when an unauthorised finder lacks the key and cannot use an unlocked session. This supports confidentiality. It does not recover a missing device or its only copy of the records, so a separate recoverable backup is also needed.

3. Evaluate rather than list

“Use MFA, a firewall and encryption” is a list. Evaluation explains why those choices suit this club and what they cost in money, effort or inconvenience.

For a small dataset, frequent full backups may be simpler to manage than a long incremental chain. A larger dataset might change that judgement. More frequent backups reduce possible missing changes but need suitable storage and management. Limiting permissions reduces opportunities for damage but requires access to be updated when roles change.

Priority depends on context. Avoid inventing numerical likelihoods or claiming one control solves every problem. Label assumptions: for example, assume the school-approved records application supports individual permissions.

4. Make the plan testable

“Keep backups” is incomplete. Specify who checks success and performs a restoration test. “Only treasurers can edit” should be tested with fictional member and treasurer roles in an authorised test environment, or described as a paper walkthrough. Do not change actual school permissions for this lesson.

Use acceptance statements: “A member cannot edit another member's payment”; “The supervisor can recover a sample record within one school day”; “An outgoing treasurer's editing access is removed.” These describe observable outcomes.

YouTube viewing

  1. Core: Cybersecurity Architecture: Five Principles to Follow (and One to Avoid) — IBM Technology. Watch 07:55–09:50, separation of duties. Use the remaining 5-minute window to explain why oversight of financial changes can help even when treasurers are trusted.
  2. Optional review: What is the CIA Triad — IBM Technology. Rewatch with your draft plan. Find a control for each goal and identify which goal has the weakest coverage.

Your main activity — One-page security plan

Use these six headings. Aim for about 400–550 words plus a compact permissions table.

  1. Priority risks: Name three risks, explain likelihood and impact qualitatively, and select your first priority.
  2. Controls: Recommend five controls. Link each to a mechanism and security goal. Include prevention, a way to detect problems and recovery.
  3. Permissions: Define the member, treasurer and supervisor roles. State any application assumptions.
  4. Recovery: Give a schedule, protected storage arrangement, responsible person and restoration-test procedure. Address the one-school-day target.
  5. Response: State what a student reports, to whom and through which known channel. Describe what authorised IT staff handle.
  6. Trade-offs and checks: Explain two costs or limitations and give two observable tests.

Self-review — 12-point learning checklist

Award 0 for missing, 1 for partial and 2 for clearly explained in each category.

CategoryWhat earns 2 points
RisksThree scenario-specific risks and a justified priority
ControlsFive complementary controls with mechanisms, including detection and recovery
PermissionsRoles have justified access; members do not receive unnecessary rights
RecoveryFrequency, protected location, responsibility and a test tied to the recovery target
ResponsePrompt reporting and appropriate IT-led containment/investigation/recovery
EvaluationTwo meaningful trade-offs and two observable checks

Aim for 10/12, then improve the lowest-scoring category. This is a learning checklist, not an examination grade.

Model elements — Compare after drafting

A defensible plan might combine individual accounts with MFA, restricted editing, disk encryption, protected versioned backups, and monitored account/edit logs. It could specify nightly backups, a weekly success review and a monthly sample restoration, with frequency increased if a day's missing changes becomes unacceptable. These frequencies are example design choices, not universal rules.

The teacher should own oversight and coordinate with school IT; students should not be assigned unsupervised system administration. A recovery-time target must be tested, not assumed from the backup schedule. A usable plan also names what happens when a treasurer leaves.

Exit question: Explain one change you would make if the club grew from 80 to 8,000 members. A strong answer connects the changed scale to impact, access administration or recovery requirements.

Key terms: justification, trade-off, residual risk, acceptance check, separation of duties.