F195 Step-by-Step Guide

OCR sets the assignment and gives you a scenario: an organisation with a described network, some existing security measures, and a set of problems. Everything you produce must be about that organisation. Generic answers about cyber security in general do not achieve the criteria.

The work runs in four tasks, and they build on each other in a single chain:

• Task 1: find the risks in the scenario, score their severity, and state your assumptions.
• Task 2: audit what the organisation already does, and find the gaps that leave the Task 1 risks uncovered.
• Task 3: design access control policies, prevention measures and written user policies that close those gaps.
• Task 4: describe, explain, analyse and evaluate what you designed in Task 3.

The six topic areas exist to give you the tools for the four tasks. This is what each one is for:

• Topic Area 1, concepts and threats: the three pillars of information security (people, process, technology), the CIA triad and IAAA, threat types (active and passive, internal and external), threat impacts (DoS, destruction, corruption and disclosure of information, elevation of privilege, theft), threat information sources (CVE lists and NCSC threat reports), and countermeasures split into preventative (security policies and procedures, testing of systems and staff, pen testing), detective (pen testing, digital forensics) and corrective (business continuity plan, cyber security insurance). D3 is marked directly against Topic Area 1.1.
• Topic Area 2, risks: the named risks (contractor access, employee access, IoT devices, network access, RPA and bots, serverless functions, service accounts), the reasons for doing risk assessments, the five stages (identification, analysis, evaluation, treatment, review and monitoring), qualitative and quantitative types, and the risk matrix built from impact and likelihood. This is Task 1.
• Topic Area 3, audit and network access control: internal (first party) and external (second and third party) audits, the audit process, and findings recorded as points of strength, observations, gaps, minor or major non-conformity (NCR), and opportunities for improvement. Also firewalls (packet-filtering, proxy and application-level gateways, stateful and stateless inspection, rules management, NAT), wireless security (encryption standards, MAC filtering, guest access, SSID protection), hardening (backup resources on demand, firmware, web filtering) and IDS and IPS. This is Task 2 and part of Task 3.
• Topic Area 4, access control: the models (MAC, DAC, RBAC, ABAC, PBAC), administration types (centralised, co-operative, decentralised, hierarchical, ownership-based), user access principles (group policy management, least privilege, privilege escalation, segregation of duties), authentication methods (passwords, biometrics, tokens, MFA) and physical security (deterrence, delay, detection, denying a breach, perimeter intrusion detection). This is P6, P7 and P8.
• Topic Area 5, written user policies: policy writing considerations, and the four named policies: AUP, Remote Access Policy, BYOD policy and Password Management Policy. This is P9.
• Topic Area 6, review: accessibility and user friendliness of policies, conformity with CIA and IAAA, and suitability of the measures. This is Task 4.

Number your risks R1, R2, R3 and your gaps G1, G2, G3 from the very start, and give every policy and measure you design a reference such as PM1. Nine of the 24 criteria ask you to talk about "each" risk, gap, policy or measure, so a reference system is the difference between an examiner seeing full coverage and seeing a general discussion.

Keep one document per task, each with a contents page and clear headings that name the criterion being evidenced. Your teacher has to find the evidence for each criterion to award it, and OCR is explicit that if the work does not fully meet a criterion, it must not be awarded.

Build a risk assessment table yourself, then populate it with every risk in the scenario. The assessment guidance is explicit: it must cover all risks detailed in the scenario, and you must not be given a template.

A workable column set, which you can justify from Topic Area 2.2:

• Ref (R1, R2, R3, and so on)
• Risk and where it sits in the organisation
• Asset affected (network, device, application, data)
• Threat type (active or passive, internal or external)
• Existing control, if any
• Impact and likelihood scores
• Severity (the product, filled in at P2)
• Treatment (treat, tolerate, transfer or terminate)

Sweep the scenario against the named risks from Topic Area 2.1 so nothing is missed: contractor access, employee access, IoT devices, network access, RPA and bots, serverless functions and service accounts. Say which risk-assessment type you used, qualitative or quantitative, and why it suits the organisation.

Draw a risk matrix with impact on one axis and likelihood on the other, then place every risk from P1 on it. The guidance says you must define the severity of all risks identified in P1, using the risk matrix format from Topic Area 2.2 or another standard format you have been taught.

Include a key that defines what each score means in words, for example what separates an impact of 3 from an impact of 5 for this organisation. Then carry the resulting severity back into the severity column of your P1 table so the two documents agree.

State three assumptions you had to make when defining severity. The scenario will never tell you everything, and the gaps you filled in are the assumptions.

Useful places to look for them: how many staff actually have administrator rights; whether backups are tested rather than just taken; how often the organisation patches; whether contractors are supervised on site; what the organisation would lose per hour of downtime; whether anyone reviews the logs.

For each risk in P1 and P2, explain the effect on the organisation's network and on its data security. The guidance names both, so cover both for every risk.

An explanation needs a mechanism, not a label. Weak: "this risk affects data security." Strong: "R4, service accounts with unchanged default passwords, would let an attacker authenticate as a trusted account. Because service accounts are usually over-privileged and their activity looks routine, the attacker could move across the file and database servers unnoticed, so the risk is loss of confidentiality of customer records and loss of integrity if those records were altered."

Naming the CIA element each risk attacks is a straightforward way to keep every explanation anchored to data security.

Take the three assumptions from P3 and justify each one: why it was reasonable to assume that, what evidence in the scenario points to it, and what your severity scoring would look like if the assumption turned out to be wrong.

That last part is what lifts a justification above a restatement. For example: "I assumed backups are not tested, because the scenario mentions a backup routine but no restore testing. If they are in fact tested monthly, the severity of R7 drops from high to medium, because recovery time would be far shorter."

Evaluate the tools and techniques you used to identify the risks and set their severity. The guidance requires an assessment of their effectiveness, so a description of what you did is not enough.

Cover, for each technique you used:

• what it found that other techniques would have missed
• where it was weak or subjective, for example a qualitative matrix depending on your own judgement of impact
• what it could not see at all, such as risks that only a technical scan or an interview with staff would reveal
• an alternative you could have used, such as a quantitative assessment with financial values, and whether it would have been better here

Finish with a judgement: overall, how confident are you in the severity ordering, and which risks are most likely to be mis-scored.

Audit all the existing cyberattack policies, procedures and methods the organisation already uses. The guidance uses the word "all", so build a checklist from the scenario first and tick items off, rather than writing about the two or three that are easiest to discuss.

Set the audit out in the format from Topic Area 3.1, with a row per measure and these findings columns:

• Points of strength, what the measure does well
• Observations, neutral notes that are not yet failures
• Gaps, where protection is absent
• Non-conformity (NCR), marked minor or major
• Opportunities for improvement

State the audit type you are performing and why. An internal (first party) audit is the organisation checking itself; a second party audit is a customer or partner checking a supplier; a third party audit is an independent body, which is what certification to ISO 27001 requires. For this assignment you are normally acting as an internal auditor or an invited consultant, so say which and note the limitation that comes with it.

Cover the technical measures as well as the paperwork: firewall configuration and rules, wireless security, patching and firmware, backups, web filtering, access rights, and any existing written policies.

Identify where the existing policies, procedures and methods do not sufficiently protect the organisation from the risks you found in Task 1. That wording comes straight from the assessment guidance, and it is the reason your gaps have to be traced back to risk references.

The clearest way to evidence this is a traceability table:

• Gap ref (G1, G2, G3)
• Risk it fails to cover (R4, R7)
• Existing measure that should have covered it
• Why it is insufficient

Include gaps of both kinds: measures that exist but are weak or misconfigured, and protections that are missing entirely. A risk from Task 1 with no corresponding control at all is the most important type of gap, and the easiest to overlook because there is no existing measure to write about.

M3 builds on P4. For each measure identified in the audit, assess how well it protects this organisation from cyberattack. Where you found weaknesses or non-conformities, the guidance requires you to include the impact these could have on the organisation's operations.

So each measure needs three things:

• what it does well, with a reason
• where it falls short, with a reason
• the operational consequence if that weakness were exploited: downtime, lost orders, inability to trade, breach notification duties, staff unable to work

Operational impact is the part most students omit. "The firewall rules have not been reviewed for two years" is an observation. "The firewall rules have not been reviewed for two years, so redundant permit rules remain for a supplier that no longer works with the organisation, which leaves an unnecessary inbound path to the file server and could stop order processing for a full day if it were used to deploy ransomware" is an assessment.

M4 builds on P5. Describe at least one specific improvement to each existing cyberattack policy, procedure and method used by the organisation. "Each" is the operative word: work through your P4 list and give every entry an improvement, including the ones that are working reasonably well.

Specific means the reader could act on it. "Improve the firewall" is not specific. "Introduce a quarterly firewall rule review, remove the permit rule for the former supplier's address range, and switch the guest network rule from stateless to stateful inspection so return traffic is tracked" is specific.

Draw the improvements from Topic Areas 3 and 4 so they are the ones the spec expects: firewall types and rules management, NAT, stateful inspection, wireless encryption standards, MAC filtering, guest access, SSID protection, web filtering, firmware updates, on-demand backup resources, access control models and least privilege.

D2 builds on M3 and M4. For each improvement you described, discuss how it will do both of the things the guidance names:

• reduce the risk to the organisation's network and data security
• improve the organisation's overall cyber security

Those are different points. The first is specific and traceable: "reviewing the firewall rules removes the inbound path behind G2, dropping R4 from high to low severity." The second is about posture: "a scheduled review also creates a repeatable process and an audit trail, which moves the organisation from reacting to incidents towards managing risk continuously, and is a requirement of ISO 27001."

A discussion weighs things up, so acknowledge cost, effort and any trade-off. An improvement that is technically ideal but that the organisation cannot staff is worth saying so about, and saying what you would do instead.

Design the policy controlling how people reach the systems from outside the organisation: remote workers, contractors, suppliers and anyone connecting over the internet. The guidance says to choose appropriate methods and use them to design policies that improve this organisation's security, drawing on Topic Areas 3 and 4.

Use the access control policy content list from Topic Area 4.2 as your structure, so nothing required is missing:

• Business and client requirements, why external access is needed at all
• User needs, who connects and for what
• Access control model used, for example RBAC, and why it fits
• User access control, which resources external accounts reach and which they cannot
• User authentication, for example MFA mandatory for all external connections
• Physical security, where relevant to off-site working

Cover the practical mechanisms: VPN with named accounts rather than a shared credential, time-limited contractor accounts with an expiry date, restriction by source address where possible, and logging of every external session for accountability.

Now design the policy for access from inside the network: staff on site, on the wired LAN and on the wireless network. Use the same structure as P6 so the two policies are comparable, but the content must be genuinely different, because the threat model is different.

Points that belong here:

• the access control model for internal systems, and how it is administered (centralised through a domain controller is usual, so justify it against decentralised or ownership-based)
• principle of least privilege and group policy management
• segregation of duties for sensitive processes
• how privilege escalation is prevented and detected, including separate administrator accounts
• authentication standards for internal accounts, and the wireless side: encryption standard, guest network separation, MAC filtering and SSID protection
• physical security using the four functions from Topic Area 4.1.4: deterrence, delay, detection and denying a breach, with perimeter intrusion detection such as CCTV and biometrics

Design the access rights themselves, group by group. Take the roles named in the scenario, for example administrators, finance, sales, technicians, contractors and guests, and set out exactly what each group may do.

A permissions matrix evidences this best: user groups down the side, systems and data stores across the top, and the permission in each cell (none, read, read and write, modify, full control). Add a short justification under the matrix for each group, tied to least privilege.

Cover the lifecycle as well as the grid: how a new starter is granted rights, how rights change when someone moves department, and how rights are removed on the day someone leaves. Leaver accounts are one of the most common real gaps and are usually present in the scenario.

Design the written policies that tell staff how technology should be used. The guidance says Topic Area 5 contains the common written user policies, and that you only need to design those which are appropriate to the organisation in the scenario, so select and justify your selection rather than writing all four by default.

The four named policies and the content each needs:

• Acceptable Use Policy: device use, email, internet and social media use, data use, consequences of misuse
• Remote Access Policy: the procedure for connecting off site, the options and use of remote connections, email, extranet and data use, consequences of misuse
• BYOD Policy: SSID and wired connection use, data and network access, device monitoring, consequences of misuse
• Password Management Policy: password requirements, how passwords are administered and managed, consequences of misuse

Apply the policy writing considerations from Topic Area 5.1 and say that you have: clear goals, broken into manageable sections, impacts analysed before rules were set, a clear structure, stakeholder feedback, a review cycle, and a stated format (on screen, paper or digital). Topic Area 5.1 also makes a specific point that these policies should contain more DOs than DON'Ts, so write them positively and show that you did.

Design cyber security prevention measures that make use of an Intrusion Detection System and an Intrusion Prevention System. This is the criterion where the technical design lives, and the guidance says the designs must include how the systems will be set up and configured, and could include diagrams as well as written text.

Decide and justify, for each system:

• Detection type: anomaly-based, which catches unknown attacks but produces false positives, or signature-based, which is precise but blind to new threats. Many designs use both.
• Deployment method: network, host, distributed, gateway or application for the IDS; network, host or wireless for the IPS.
• Components: where the sensors sit, where the analyser runs, and who watches the user interface.
• Placement: what each sensor can and cannot see, and why that position covers the risks from Task 1.
• Response: what the IPS blocks automatically, what only alerts, and who acts on the alerts.

A labelled network diagram showing sensor placement, the firewall and the segments being monitored is worth including. You are not required to implement anything, although the guidance notes that if your centre has the facilities, you could demonstrate the policies as part of your evidence.

The guidance points you at a specific place: use the content in Topic Area 1.1 to discuss how well each prevention policy and measure relates to the concepts of cyber security. That means the three pillars, the CIA triad and IAAA, applied to every policy and measure you designed.

Work through each design and answer:

• which of people, process and technology it addresses, and whether it leaves one of the three untouched
• which parts of CIA it protects, and whether it weakens another part in doing so
• which stages of IAAA it implements: does it identify, authenticate, authorise, and does it leave an accountable record?

The strongest answers point out the imbalances. A password management policy is a process and people control that supports confidentiality and the authentication stage of IAAA, but on its own it does nothing for availability and leaves no audit trail, which is why it is paired with logging and MFA. Justifying the combination rather than each item in isolation is what makes this a Distinction response.

Describe the purpose of each policy and measure you designed in Task 3. This is the simplest criterion in Task 4 and the easiest to lose by covering only some of your designs.

List every design by its reference, then give each one a short paragraph: what it is for, who it applies to, and which gap from Task 2 it exists to close. Keep it descriptive here. The explaining, analysing and evaluating come in the criteria that follow, and repeating them early does not earn the marks twice.

The spec is unusually direct that P11 and P12 have different focuses, and students routinely write the same thing twice and lose one of them.

P11 is about eliminating exposure. Explain how each policy and measure aims to remove the organisation's exposure to cyber security threats that could cause a loss. The question is: what route does this close, and how?

Example: "PM3, mandatory MFA on all external connections, removes the exposure created by a stolen or reused password. Even if a contractor's credentials are phished, the attacker cannot complete authentication without the second factor, so the remote access route is closed rather than merely monitored."

P12 is about the risk that remains. Explain how each policy and measure reduces the likelihood and the severity of a possible loss. Both words are in the criterion, and both need to be addressed for each design.

This is where your Task 1 risk matrix earns its keep, because likelihood and severity are the two axes you already scored. Say what each score was before the design and what it becomes after.

Example: "PM3 reduces the likelihood of R4 from 4 to 2, because credential theft alone is no longer sufficient to gain access. Severity stays at 4, because if MFA were bypassed the contractor account still reaches the finance share, which is why PM3 is paired with the least-privilege changes in PM5."

Explain how the organisation in the scenario would actually implement the policies you designed. The guidance sets two conditions:

• the explanation must be at a high level rather than a step-by-step guide, so describe the approach, sequence, resources and responsibilities, not a click-by-click configuration walkthrough
• you must also explain how you would roll out the written policies to staff

For the technical designs, cover who does the work, what it depends on, roughly how long it takes, whether a pilot or phased rollout is sensible, and what could disrupt users during the change.

For the written policies, the rollout is a separate piece: how staff are told, how they are trained, how they acknowledge the policy, where it is stored so people can find it later, and how new starters receive it. That second half is a stated requirement and is the part most often missed.

Analyse the advantages and disadvantages of each policy and measure. Every design needs both, including the ones you are most confident about. A design with no stated disadvantage reads as unanalysed.

Useful angles for the disadvantage side, since that is the harder half:

• cost of licences, hardware or staff time
• the burden it places on users, and the chance they work around it
• new single points of failure, for example a centralised authentication server
• false positives and the alert fatigue an IPS or anomaly-based IDS can create
• ongoing maintenance the organisation may not have the staff to sustain
• what the measure still does not cover

Analysis breaks something into parts and shows how they relate, so connect the two sides: "the advantage of automatic blocking is that the attack stops without waiting for a human, but the same automation is the disadvantage, because a false positive blocks a legitimate customer and there is nobody on shift overnight to release it."

D4 builds on M6. Discuss how the users of the organisation's system will be affected when your policies and measures are implemented. The guidance requires two specific things:

• how their usage may change
• any negative impact they may experience

Go group by group, using the same user groups as P8, because different groups feel different effects. Administrators gain extra steps and lose convenience; finance staff may lose access to shares they were used to reaching; contractors face expiring accounts and MFA on a personal phone; guests are pushed onto a separate SSID with no internal access.

Name the friction honestly: slower logins, extra devices to carry, requests that now need approval, personal devices subject to monitoring under a BYOD policy, and the training time the rollout consumes. Then say how you would reduce that friction, because a discussion that only lists problems is incomplete.

This is the criterion that closes the chain, and the guidance is precise about what it wants. Evaluate how well your policies and measures ensure that:

• the more severe risks identified in Task 1 are mitigated
• the insufficiencies and gaps identified in Task 2 are mitigated

And then the sentence that catches most students out: if any gaps in protection remain, you must justify why they have not been addressed.

Structure it as a closing traceability table: every high-severity risk and every gap reference down one side, the design that addresses it, your judgement on how effectively, and a residual risk rating. Then write the evaluation underneath, reaching a clear verdict on which of your designs is the most effective for this organisation and which is the weakest.

Leaving a gap unaddressed is allowed, and sometimes correct: the cost may exceed the risk, the organisation may not have the staff, or the control may block something the business needs. Say which gap remains, why you accepted it, and what would have to change for you to revisit that decision. Use the review techniques from Topic Area 6.1 as your criteria: accessibility and user friendliness of the policies, conformity with CIA and IAAA, and suitability of the planned measures.

• OCR sets the assignment. Your centre does not write it, and each assignment stays live for two years, with a new one released annually. The front cover names the cohort it is for.
• The work must be yours alone. Your centre has to have controls in place to make sure of it, and completed work for a live assignment cannot be shared with other students as an example.
• One resubmission. If you have not performed at your best, you can improve the work and submit it again for assessment, once per assignment, with your teacher's agreement. Your teacher can tell you that a criterion has not been met, but must not tell you specifically what to change.
• Authentication. A teacher who knows your work has to confirm it is yours, so keep drafts, notes and version history as you go.
• Plagiarism and AI misuse. Specification version 5 expands this section specifically to cover AI misuse, and requires that you are taught how to reference or acknowledge material copied from the internet or any other source. Anything you did not write yourself, including AI-generated text, must be acknowledged.
• Moderation. Your centre marks the work and OCR moderates it, in one of two windows each year.
• Grading. Unit grades are compensatory, based on the total criteria achieved, and criteria you achieve still earn uniform marks towards the qualification even if the unit is not passed.