When Security Theory Meets a Filing Cabinet: A Reflection on Risk Assessment Fieldwork

Before this module, "risk assessment" was a phrase I associated with spreadsheets and shading cells red, yellow, and green. Our group's fieldwork changed that. We spent an afternoon at a small community-based office — the kind of organization that runs on a handful of staff, a few desktop computers, a printer that jams more than it prints, and a filing cabinet that has quietly become the backbone of how resident and beneficiary records are kept. Nothing about the place looked like a target. That, it turned out, was exactly the point our lessons had been trying to make: risk doesn't announce itself, and the organizations least equipped to manage it are often the ones holding the most sensitive information about the people they serve.

This post is a reflection on what that fieldwork actually taught us about information security in practice — not a rundown of what we found wrong with any one office. In keeping with the confidentiality expectations of the exercise, I'm deliberately staying at the level of categories and reasoning rather than specifics. What I want to walk through instead is how we thought: how we identified assets, how we reasoned about likelihood and impact, and how we moved from "this could go wrong" to a treatment we could actually recommend to people running on a shoestring budget and no dedicated IT staff.

Starting With Assets, Not Threats

The instinct going in was to look for problems first — walk around and spot the things that seemed unsafe. Our lessons pushed us the other way: start by inventorying what actually needs protecting. This mirrors the approach in NIST's guide for conducting risk assessments, which frames risk assessment as fundamentally about identifying threats and vulnerabilities in relation to specific assets, rather than treating "security issues" as a free-floating list (National Institute of Standards and Technology [NIST], 2012). Once we actually listed the assets — resident records, staff login credentials, the office's single shared computer, printed forms containing personal information, the physical space itself — the exercise stopped feeling abstract. Each asset came with its own question: who can access this, under what conditions, and what happens to the people behind that data if it's exposed, altered, or lost.

That reframing mattered more than any single finding. A locked drawer isn't "good" or "bad" in isolation — it's only meaningful once you know what's inside it and who has a legitimate reason to open it. Several of our group's early observations turned out to be non-issues once we asked "does this actually expose an asset," and a few things we'd initially dismissed as unimportant turned out to matter a great deal once we traced them back to a record that could identify a real person.

Reasoning Through Likelihood and Impact

The methodology we applied was a standard qualitative risk matrix: for each identified vulnerability, we estimated likelihood (how plausible is it that this gets exploited or fails, given the environment) and impact (how much harm results if it does). This two-axis approach is a simplified but faithful application of the risk analysis stage described in ISO/IEC 27005, which frames information security risk as the product of how likely an event is and the consequence it would have for the organization and the individuals whose data it holds (International Organization for Standardization [ISO], 2022).

What surprised our group was how often likelihood and impact pulled in different directions. Some risks we flagged had genuinely low likelihood — the kind of scenario that would require deliberate, sustained effort to exploit — but carried high impact because the data involved was sensitive personal information tied to vulnerable individuals. Others were the reverse: everyday habits, repeated dozens of times a week, that individually carried low impact but whose likelihood of eventually causing a problem was close to certain. Learning to sit with that mismatch, rather than defaulting to whichever risk "felt" scariest, was probably the single most useful shift in thinking the fieldwork produced. It's easy to fixate on a dramatic worst case and overlook the mundane process failure that's actually far more likely to bite first.

We also had to reckon with a category our lessons had warned us about but that felt different once we saw it in person: administrative and procedural risk. It's tempting, especially for IT students, to think of security almost entirely in technical terms — passwords, firewalls, encryption. But a meaningful share of what we found sat in process gaps: no documented procedure for who reviews access to records, no consistent practice for what happens to physical documents once they're no longer needed, no shared understanding among staff of what counted as sensitive information in the first place. None of that shows up in a vulnerability scanner. All of it showed up the moment we asked simple "what happens if" questions.

From Finding to Treatment: Choosing What to Recommend

Identifying a risk is the easier half of the exercise. The harder half — and the part that actually tested what we'd learned — was deciding what to recommend, given that this wasn't an organization that could throw a budget at the problem. Our lessons framed treatment options along four familiar paths: avoid, mitigate, transfer, or accept the risk. In a well-resourced enterprise, mitigation is often the default answer. In a small community office running on limited staff time and no IT budget, that default breaks down fast.

We ended up leaning heavily on low-cost, procedural mitigations rather than technical ones: recommending clearer rules about who handles which records, suggesting a basic access log for shared devices, proposing a simple retention schedule so old records didn't sit around indefinitely, and flagging where a small habit change — not a purchase — would close most of the gap. For a couple of lower-likelihood, high-impact risks tied to physical records, we recommended treatments closer to risk avoidance: simply not retaining certain categories of sensitive information longer than necessary, since the safest copy of a record is often the one that no longer exists once its purpose is served. This is consistent with the data privacy principles under the Philippine Data Privacy Act (Republic Act №10173), which requires that personal information be collected and retained only for as long as necessary to fulfill a declared, specified, and legitimate purpose, and that organizations processing such data implement reasonable and appropriate security measures proportionate to the risk involved (Republic Act №10173, 2012).

That proportionality principle became our filter for every recommendation. It would have been easy to hand over a checklist copied from an enterprise security framework — the kind that assumes a dedicated system administrator and a procurement budget. It would also have been useless. The organization we assessed wasn't going to implement multi-factor authentication or a formal document management system by next month. What it could plausibly do was tighten a habit, assign clear ownership of a task, and stop keeping information it no longer needed. Learning to scale a recommendation down to what an organization can actually sustain, without pretending the underlying risk isn't real, felt like the most practically useful skill the fieldwork produced.

What This Actually Taught Us About Information Security in Practice

The biggest lesson wasn't any individual finding — it was how differently risk looks in the field compared to in a case study. Case studies arrive pre-sorted: someone has already decided which details matter. Fieldwork doesn't come pre-sorted. We had to decide, as a group, which of dozens of small observations were actually worth escalating, and we had to defend that reasoning to each other before we ever wrote it down. That process of disagreement and justification did more to teach us the logic of risk assessment than any lecture slide could, because it forced us to articulate why one gap mattered more than another instead of just listing gaps.

It also reframed how I think about who's actually vulnerable to poor information security practice. Small, resource-constrained organizations aren't marginal cases in security thinking — they're often exactly where the most sensitive, hardest-to-replace personal data sits, precisely because they lack the capacity to protect it the way a larger institution could. Recognizing that gap between an organization's obligations under the law and its practical capacity to meet them, and then finding recommendations that respect both, is a more honest picture of what information security work actually looks like than any purely technical exercise could have given us.

References

International Organization for Standardization. (2022). Information security, cybersecurity and privacy protection — Guidance on managing information security risks (ISO/IEC 27005:2022).

National Institute of Standards and Technology. (2012). Guide for conducting risk assessments (NIST Special Publication 800–30, Rev. 1). U.S. Department of Commerce. https://doi.org/10.6028/NIST.SP.800-30r1

Republic Act №10173, Data Privacy Act of 2012. (2012). Congress of the Philippines. https://privacy.gov.ph/data-privacy-act/