How to Write a Risk Methodologies and Analysis Paper: Information Systems Security Risk Assessment
A section-by-section guide to structuring your IS security risk assessment paper — what belongs in each part, how to address the four assignment prompts, which frameworks to reference, and where most students lose marks before they reach the risk mitigation discussion.
You have an assignment that asks you to address four distinct prompts about information systems security risk assessment — rationales, methodology types, data collected, and common tasks. Each prompt maps to a specific section of the paper with its own required content and logic. Combining all four into one undifferentiated block of text, or answering only the parts you are most comfortable with, is how most students lose marks on this paper. This guide breaks down each section, explains what content belongs where, and points to the frameworks and sources that support the arguments the rubric expects to see.
This guide does not write the paper for you. It explains the structure, the content expectations per section, and the reasoning behind each component so you can apply that to your own paper. The framework here applies to any IS security risk assessment paper built around the four prompts in the assignment instructions.
What This Guide Covers
What an IS Security Risk Assessment Actually Is
An information systems security risk assessment is a structured process for identifying threats to an organisation’s information assets, evaluating the likelihood and potential impact of those threats being realised, and determining the appropriate controls needed to reduce risk to an acceptable level. It is not an audit, not a compliance checklist, and not a penetration test — though it may inform all three. Understanding this distinction matters because the paper asks you to discuss risk assessment as a deliberate analytical methodology, not as a technical scan of vulnerabilities.
The core logic of any risk assessment is straightforward: risk is a function of threat likelihood and asset impact. What varies across methodologies is how you measure those two variables — whether you assign numeric values (quantitative), descriptive categories (qualitative), or a combination (hybrid). The assignment requires you to explain all three, identify when each is appropriate, and demonstrate that you understand the conditions that make one more suitable than another.
Threat
Any event or actor that could cause harm to an information asset — malware, insider threats, natural disasters, human error. Threats are identified during the assessment, not assumed in advance.
Asset
Any information system component with value to the organisation — hardware, software, data, processes, personnel. The asset inventory is one of the first outputs of a risk assessment.
Risk
The potential for loss or harm resulting from a threat exploiting a vulnerability in an asset. Risk = Likelihood × Impact. Reducing either factor reduces overall risk.
How to Structure the 3–4 Page Paper
The assignment has four numbered prompts. Those four prompts map directly to four sections of your paper. Do not try to consolidate them — each prompt tests a different aspect of your understanding, and mixing them makes the paper harder to mark against the rubric.
At standard APA formatting (12pt Times New Roman or 11pt Calibri, double-spaced, 1-inch margins), 3–4 pages is approximately 900–1,200 words of body text, excluding the title page and reference list. With four substantive sections to cover, that is roughly 200–300 words per section — enough for two to three developed paragraphs each. This means you cannot treat any section as a throw-away. Every section needs substantive content. If you find yourself at three pages without having addressed all four prompts, some sections are too long. If you finish all four prompts in two pages, some sections are too thin.
Section 1: Three Rationales for Performing a Risk Assessment
The paper asks for “at least three rationales” — meaning three distinct, separately argued reasons why an organisation would conduct an IS security risk assessment. These are not the same as the benefits of good security in general. They are specific justifications for the assessment process itself.
Three rationales that are well-supported in the IS security literature and aligned with frameworks like NIST SP 800-30 are: regulatory and compliance obligations, informed resource allocation, and organisational risk awareness. Your paper should develop each one, not list them. What follows is guidance on the substance of each rationale so you can construct your own argument.
Rationale 1: Regulatory and Compliance Obligations
Many industries and jurisdictions require organisations to conduct formal risk assessments as a condition of regulatory compliance. HIPAA requires covered entities in healthcare to conduct a security risk analysis. PCI-DSS requires merchants handling card data to perform risk assessments. The Federal Information Security Management Act (FISMA) mandates risk assessments for federal agencies. The rationale here is not voluntary — organisations in regulated sectors conduct risk assessments because they are legally required to, and failure to do so exposes them to penalties, loss of certification, or legal liability. Your paper should explain this rationale by connecting it to the compliance landscape and citing at least one specific regulatory requirement.
Rationale 2: Informed Resource Allocation and Security Investment
Organisations have finite budgets for information security. Without a risk assessment, security spending is based on intuition, vendor recommendations, or reaction to recent incidents — none of which systematically prioritises resources toward the highest-risk assets and threats. A risk assessment produces a ranked view of risks, allowing the organisation to direct security controls toward the vulnerabilities that pose the greatest potential harm. This rationale is sometimes framed as cost-justification for security spending: the assessment identifies where investment will have the greatest risk-reduction impact. Whitman and Mattord (2021) address this argument directly in the context of information security management.
Rationale 3: Organisational Risk Awareness and Decision Support
Senior leadership and boards of directors increasingly treat cybersecurity as a governance issue rather than a purely technical one. A risk assessment translates technical vulnerabilities into business-impact terms — financial loss, reputational damage, operational disruption — that non-technical decision-makers can act on. This rationale positions the risk assessment as a communication tool between the security function and organisational leadership, supporting risk-informed decision-making across the enterprise. NIST SP 800-30 describes this function explicitly as risk framing — establishing the context and criteria under which risk-based decisions will be made.
A rationale like “organisations should perform risk assessments because cybersecurity threats are increasing” does not answer the prompt. The prompt asks why you would perform an assessment specifically, not why security matters in general. Every rationale must connect to what the assessment process produces — a documented, structured analysis of risk — and why that output is necessary. If your rationale would apply equally to any security activity (firewalls, training, encryption), it is not specific enough to the risk assessment as a methodology.
Section 2: Quantitative, Qualitative, and Hybrid Methods — Differences and Conditions
This is the section where the most marks are lost, because it has two sub-requirements: explain the differences between the three approaches, and explain the conditions under which each is most applicable. Most students address the first but skip the second. Defining what each method is and then moving on is not sufficient — the assignment explicitly requires you to illustrate when each type is most applicable.
Quantitative Risk Assessment
Quantitative risk assessment assigns numeric values to both the likelihood of a threat occurring and the potential financial impact of that threat being realised. The two core metrics are Annualised Loss Expectancy (ALE) and Single Loss Expectancy (SLE). ALE = SLE × Annualised Rate of Occurrence (ARO). If a server breach has an SLE of $50,000 and the organisation estimates it occurs once every two years (ARO = 0.5), the ALE is $25,000. This figure can be used to evaluate whether a proposed control costing $15,000 per year is financially justified.
When Quantitative Is Most Applicable
Quantitative methods are most appropriate when:
- Historical incident data exists to calculate realistic loss values and occurrence rates
- The organisation needs to justify security spending in financial terms to non-technical leadership
- Insurance or regulatory contexts require documented financial risk figures
- The assets at risk have clearly measurable monetary value (financial systems, transactional databases)
Limitations of Quantitative Methods
The numbers are only as reliable as the data behind them. For new threat types, novel attack vectors, or intangible assets like reputation, reliable historical data often does not exist. Assigning a precise dollar figure to a brand damage scenario introduces false precision. ALE calculations assume stable threat environments that do not hold for rapidly evolving threat landscapes.
Qualitative Risk Assessment
Qualitative risk assessment uses descriptive scales rather than numeric values — High/Medium/Low, or a 1–5 ordinal scale for likelihood and impact — to characterise risk. Assessors apply expert judgment, interviews, and scenario analysis to rate risks across the scale. The output is typically a risk matrix that plots likelihood against impact and places identified risks in cells that indicate priority. This approach does not produce ALE figures but produces a ranked view of risk that is interpretable without statistical or financial modelling expertise.
When Qualitative Is Most Applicable
Qualitative methods are most appropriate when:
- The organisation lacks historical incident data needed for reliable quantitative calculations
- Time and budget constraints make a full quantitative analysis impractical
- Assets include intangible components like reputation, customer trust, or strategic capability
- The assessment team includes non-financial stakeholders whose input cannot be reduced to numeric estimates
Limitations of Qualitative Methods
The ratings are subjective. Two different assessors evaluating the same threat may assign different likelihood ratings based on their experience and risk appetite. Without numeric anchors, comparing risks across different categories becomes difficult. Qualitative results cannot directly support financial cost-benefit analysis of security controls.
Hybrid Risk Assessment
Hybrid assessment combines elements of both. A common approach is to use qualitative ratings to identify and prioritise risks first, then apply quantitative analysis only to the highest-priority risks where the investment in data collection and calculation is warranted. This preserves the efficiency of qualitative screening while generating the financial precision of quantitative analysis where it matters most.
When Hybrid Is Most Applicable
Hybrid methods are most appropriate when the organisation has a mix of asset types — some with clear monetary value and historical data, others that are intangible or novel. Large enterprises conducting organisation-wide assessments across diverse business units often use hybrid approaches to maintain consistency at the portfolio level while enabling deeper quantitative analysis at the asset or system level. Hybrid approaches are also common when regulatory requirements specify qualitative outputs (risk ratings) but internal governance demands financial justification for security investments.
| Characteristic | Quantitative | Qualitative | Hybrid |
|---|---|---|---|
| Primary output | Dollar-value ALE figures; ROI on controls | Risk ratings (High/Med/Low); priority matrix | Both, applied selectively |
| Data requirement | High — needs historical incident data | Low — relies on expert judgment | Medium — qualitative screening, quantitative deep-dives |
| Time and cost | High — complex data collection and modelling | Lower — interviews, workshops, expert panels | Variable — scope depends on which risks receive quantitative treatment |
| Best for | Financial systems, regulated industries, insurance contexts | Early-stage assessments, intangible assets, resource-constrained environments | Large enterprises; mixed asset portfolios; when both financial and priority outputs are needed |
| Key limitation | Data availability; false precision without reliable historical data | Subjectivity; not directly convertible to financial cost-benefit analysis | Complexity of maintaining consistency across two methodological approaches |
Section 3: Types of Information Collected in an Effective Risk Assessment
The assignment requires at least three different types of information, with each type fully described and with a justification for why you selected it. “Fully describe” signals that a sentence or two per type is not sufficient — each type needs its own paragraph that covers what the information is, where it comes from, how it is collected, and why it is necessary for the assessment to be effective. Three types are the minimum; covering four or five demonstrates depth.
Three information types that are well-justified and commonly referenced in IS security risk assessment literature are: asset inventory data, threat intelligence data, and vulnerability data. A fourth — organisational context and policy data — strengthens the paper significantly and is easy to justify.
Information Type 1: Asset Inventory Data
An asset inventory documents every information system component the organisation relies on — hardware (servers, endpoints, network devices), software (operating systems, applications, databases), data repositories, and supporting processes. Without knowing what assets exist and what they are worth to the organisation, it is impossible to assess risk, because risk is always risk to something. Asset data is collected through automated network scanning tools, configuration management databases (CMDBs), interviews with system owners, and manual audits. Criticality ratings — which assets are mission-critical versus peripheral — are assigned as part of this collection. The justification for this type is foundational: every downstream step in the risk assessment depends on the asset inventory being complete and accurate.
Information Type 2: Threat Intelligence Data
Threat intelligence data identifies the threat actors, threat vectors, and threat events that are relevant to the organisation’s environment. This includes data on known attacker groups targeting the organisation’s industry sector, common attack techniques (as catalogued in frameworks like MITRE ATT&CK), historical incident data from within the organisation, and intelligence feeds from sources such as the US-CERT, ISAC (Information Sharing and Analysis Center) for the relevant sector, and commercial threat intelligence providers. Threat intelligence answers the question: what are we protecting these assets from? Without this, risk assessments default to generic threat assumptions that may not reflect the actual threat landscape facing the organisation.
Information Type 3: Vulnerability Data
Vulnerability data identifies weaknesses in the organisation’s systems, configurations, processes, or physical environment that could be exploited by the identified threats. Technical vulnerability data is collected through automated scanning tools (such as Nessus or Qualys), penetration test results, and review of CVE (Common Vulnerabilities and Exposures) databases. Non-technical vulnerabilities — inadequate access controls, missing security policies, insufficient staff training — are identified through interviews, document review, and policy gap analysis. Vulnerability data is paired with threat data: a vulnerability only becomes a risk if there is a credible threat actor capable of and motivated to exploit it. This is why vulnerability data alone is not sufficient — it must be analysed in relation to threat intelligence.
Information Type 4: Organisational Context and Policy Data
This type covers the organisation’s existing security policies, risk tolerance statements, regulatory obligations, business objectives, and operational constraints. Collecting this information establishes the boundaries within which the assessment operates. For example, an organisation with a stated risk appetite of “risk-averse” will use different thresholds for what constitutes acceptable risk than one with a “risk-tolerant” posture. Existing security policies reveal where controls are already in place, preventing double-counting of risks that are already mitigated. Regulatory obligations (HIPAA, PCI-DSS, GDPR) define minimum control requirements that shape which residual risks are permissible. NIST SP 800-30 describes this as the risk framing step — establishing the context before any threat or vulnerability data is collected.
The assignment asks you to “justify why you made your selections” — which means the paper must explain why these specific types are necessary, not merely describe them. The justification for each type should answer: what decision does this information enable? What would the assessment be unable to do without it? Asset data enables impact valuation. Threat intelligence enables likelihood estimation. Vulnerability data enables control gap identification. Organisational context enables appropriate scoping and risk tolerance calibration. Each type is necessary because the assessment is incomplete — and its outputs unreliable — without it.
Section 4: Five Common Risk Assessment Tasks
The assignment asks for at least five common tasks that should be performed in an IS security risk assessment. These are process steps — sequential activities that make up the assessment workflow. Describe what happens in each task, what it produces, and why it matters. Do not list them as bullet points. Develop each one as a paragraph, in sequence, so the paper reads as a coherent description of the assessment process from start to finish.
The following five tasks align with the NIST SP 800-30 risk assessment process and are directly applicable to the assignment prompt. Use this as a framework for your own description — your paper should express these in your own words and with reference to the sources appropriate to your course.
-
Task 1: Prepare for the Assessment (Risk Framing)
Before any data collection begins, the scope of the assessment must be defined. This includes identifying which systems and processes are in scope, establishing the risk tolerance and acceptance criteria the organisation will use to evaluate results, identifying stakeholders who will be involved, and documenting the methodology that will be applied. This task produces a risk assessment plan. Without it, assessments lack consistency — different team members may apply different criteria, producing results that cannot be meaningfully compared or aggregated. NIST SP 800-30 calls this the “prepare” step and treats it as foundational to all subsequent activities.
-
Task 2: Identify Threats and Threat Sources
This task involves systematically identifying the threat sources — adversarial (hackers, insiders, nation-state actors), accidental (human error, system failure), structural (hardware degradation, software bugs), and environmental (natural disasters, power failure) — and the specific threat events each source could initiate against the organisation’s systems. The output is a threat catalogue that is specific to the organisation’s environment and sector. Generic threat lists from published sources are a starting point, but the identification task requires tailoring to the organisation’s actual context. MITRE ATT&CK is a commonly used external source for adversarial threat cataloguing.
-
Task 3: Identify Vulnerabilities and Predisposing Conditions
With the threat catalogue in hand, the next task is identifying the weaknesses in the organisation’s systems and environment that the identified threats could exploit. Technical vulnerabilities are identified through scanning tools and CVE review. Process vulnerabilities — absence of change management controls, inadequate access provisioning procedures — are identified through document review and interviews. Predisposing conditions are organisational factors that increase susceptibility to harm: a high staff turnover rate, for example, increases susceptibility to insider threats and social engineering. This task produces a vulnerability register that maps weaknesses to the assets identified in the asset inventory.
-
Task 4: Determine Likelihood and Impact — Risk Analysis
This is the analytical core of the assessment. For each threat-vulnerability pairing identified in the previous two tasks, the assessor determines the likelihood that the threat will successfully exploit the vulnerability (given existing controls) and the impact on the organisation if it does. Depending on the methodology chosen (quantitative, qualitative, or hybrid), this task either assigns numeric probability and financial impact values, or assigns ordinal ratings on a defined scale. The product of likelihood and impact produces a risk score or risk level for each scenario. This task requires the most expertise and judgement of any step in the process, and is where qualitative subjectivity or quantitative data quality issues most directly affect the reliability of the output.
-
Task 5: Communicate and Document Risk Assessment Results
A risk assessment has no operational value until its results are communicated to the people who can act on them. This task involves producing the risk assessment report — documenting identified risks, their scores or ratings, the data and judgements behind each rating, and recommended actions for risk mitigation, acceptance, transfer, or avoidance. The report is tailored to its audience: executive summaries for leadership, technical appendices for system owners and IT teams. This task also includes presenting the findings to relevant stakeholders and obtaining sign-off on the risk treatment decisions. NIST SP 800-30 distinguishes this task from the analytical steps deliberately — documentation and communication are distinct activities that determine whether the assessment drives organisational action or sits in a file unread.
Optional Sixth Task: Monitor and Review
If you want to exceed the minimum of five tasks, risk monitoring — the ongoing process of tracking changes to the threat landscape, asset inventory, and control environment that could alter risk ratings — is a well-supported sixth task. NIST SP 800-30 treats risk monitoring as part of the risk management lifecycle that begins with assessment. Including this task signals that you understand risk assessment as a continuous process, not a one-time event. It also connects the assessment directly to the information security management system (ISMS) framework used in standards such as ISO/IEC 27001, which treats risk assessment as a recurring control requirement rather than a project deliverable.
Frameworks and Sources to Cite
The assignment requires at least two quality resources. Quality, in the context of an IS security paper, means peer-reviewed academic sources or authoritative professional standards — not blog posts, vendor white papers, or general websites. The following are strong choices that are directly applicable to all four prompts.
| Source | What It Covers in This Paper | Where to Access |
|---|---|---|
| NIST SP 800-30 Rev. 1 (2012) | Guide for Conducting Risk Assessments — the definitive US government framework. Covers the four-step assessment process (Prepare, Conduct, Communicate, Maintain), threat and vulnerability taxonomies, likelihood and impact ratings, and risk framing. Directly supports all four assignment prompts. | Free PDF from NIST: csrc.nist.gov/publications/detail/sp/800-30/rev-1/final |
| Whitman & Mattord, Principles of Information Security (current edition) | Widely used IS security textbook covering risk management concepts, quantitative and qualitative methods, asset identification, and threat analysis. Likely on your course reading list. Supports Prompts 1, 2, and 3. | University library or publisher site |
| ISO/IEC 27005:2022 | International standard for information security risk management. Provides a methodology-neutral framework that covers all five tasks and supports the discussion of hybrid approaches. Citable as an authoritative professional standard. | ISO website (purchased) or via university library database |
| ISACA Risk IT Framework | Governance-focused risk framework that connects IS risk to business objectives. Useful for the rationale section when arguing the governance and decision-support rationale for performing assessments. | isaca.org (free registration required) |
NIST Special Publication 800-30 Revision 1, Guide for Conducting Risk Assessments, is published by the National Institute of Standards and Technology and is freely available at csrc.nist.gov/publications/detail/sp/800-30/rev-1/final. It is the authoritative US federal government standard for IS risk assessment and is cited in academic, industry, and government risk management literature globally. Using it as a primary source signals methodological grounding that the rubric will reward.
Writing the Paper: Structure and Tone
IS security papers are written in the third person, present tense, with APA 7th edition formatting. The tone is analytical — you are explaining and evaluating concepts, not advocating for a particular product or vendor approach. Each section should begin with a clear topic sentence that identifies what the section addresses, develop the content with referenced evidence, and close with a sentence that connects back to the broader argument (that risk assessment is a necessary and structured component of IS security management).
Weak Section Opening
“There are many reasons why companies do risk assessments. These include compliance, money, and awareness.” This is vague, uses informal language, and provides no analytical framework for what follows.
Strong Section Opening
“Three rationales underpin the decision to conduct an IS security risk assessment: regulatory compliance obligations, informed allocation of security resources, and the generation of risk intelligence that supports organisational decision-making. Each addresses a distinct organisational need that the assessment process is specifically structured to meet.”
Describing Without Applying
“Quantitative assessment uses numbers and qualitative uses words. Both are useful depending on the situation.” This defines the methods but fails to identify the conditions under which each is applicable — which is the second half of what the prompt requires.
Defining and Applying
“Quantitative assessment assigns numeric probability and financial impact values to risk scenarios, enabling cost-benefit analysis of security controls. This approach is most applicable where reliable historical incident data exists and where financial justification of security investment is required — conditions typically found in financial services organisations and regulated healthcare environments.”
Listing Tasks Without Process Logic
“The five tasks are: identify assets, identify threats, identify vulnerabilities, analyse risks, and document results.” This is a bullet list presented as prose. It names the tasks without describing them or explaining their sequence.
Describing Tasks as a Process
“The first task, asset identification, produces the inventory of systems, data, and processes that all subsequent steps depend on. Without a complete asset inventory, threat and vulnerability identification is incomplete by definition, because risk can only be assessed relative to something of value to the organisation.”
Where Most Papers Lose Marks
Addressing Only Part of Prompt 2
Defining quantitative, qualitative, and hybrid methods but failing to explain the conditions under which each is most applicable. The prompt has two requirements — differences and conditions. Missing the second half means the section is incomplete regardless of how well you defined the methods.
Instead
After defining each method, add a sentence or two that explicitly addresses: “This method is most applicable when…” The conditions must be specific — not “when it is appropriate” but when data availability, asset type, time constraints, or output requirements make this method the better choice.
Under-describing Data Types in Prompt 3
Writing one sentence per data type: “Asset data is collected to identify what systems are at risk.” This names the data type but does not fully describe it — how is it collected, what does it contain, why is it necessary? “Fully describe” means paragraph-level treatment.
Instead
Write a full paragraph for each data type covering: what it is, how it is collected, what it contains, and why the assessment cannot function effectively without it. Each data type should be treated as its own mini-section with enough detail that a reader unfamiliar with risk assessment would understand its role in the process.
Using Only One Source for the Entire Paper
Building the entire paper around a single textbook or NIST publication. The assignment requires at least two quality resources, and a paper that cites only one source signals insufficient research regardless of how well that one source is used.
Instead
Use NIST SP 800-30 as the primary framework source for the task descriptions and methodology discussion. Use Whitman and Mattord (or equivalent textbook) for the rationales and data types sections. If a third source is available (ISO 27005, ISACA Risk IT), use it to support the hybrid methodology discussion or the regulatory compliance rationale.
Treating Tasks as a List Rather Than a Process
Presenting the five tasks as a numbered or bulleted list without connecting them into a coherent process narrative. The rubric evaluates whether you understand how the tasks relate to each other — not just whether you can name five of them.
Instead
Write the tasks in sequence and use connecting language that shows how each step builds on the previous one. “The output of Task 2 — the threat catalogue — becomes the input to Task 3…” This shows process understanding, not just list recall.
Frequently Asked Questions
What the Rubric Is Actually Testing
IS security risk assessment papers are evaluated on content accuracy, depth of analysis, use of appropriate sources, and writing quality. The content accuracy criterion tests whether you have correctly understood and applied the concepts — specifically, whether your descriptions of quantitative, qualitative, and hybrid methods are technically accurate, and whether your five tasks reflect an actual risk assessment process rather than generic project management steps.
The depth criterion tests whether you have gone beyond surface-level definition. Naming three data types is the minimum; explaining what each contains, how it is collected, and why it is necessary is the depth the assignment is designed to test. Similarly, listing five task names is the minimum; explaining what each task produces and how it feeds into the next is the depth that separates adequate papers from distinction-level ones.
The sources criterion tests whether you have grounded your arguments in authoritative frameworks rather than general knowledge or unsupported assertion. NIST SP 800-30 is the most directly applicable source for this paper and should be cited in at least the rationale section, the methodology section, and the tasks section. A course textbook provides conceptual grounding. A third source (ISO 27005, ISACA) demonstrates research breadth that the rubric will reward.
For direct support with this paper — whether you need a model paper reviewed, help structuring the four sections, or assistance with APA formatting and source integration — our IT and cybersecurity assignment writing team works specifically with IS security, risk management, and information assurance papers at the undergraduate, master’s, and doctoral level.