Spotting and Reporting Trouble

Lesson Overview

The earlier lessons in this course were about keeping trouble out: strong passphrases and MFA, recognising phishing, securing a device, handling and backing up information, browsing safely, avoiding malware and scams, keeping software updated, and guarding your privacy. This last lesson is about what happens when, despite all of that, something goes wrong anyway. No set of defences is perfect, and the question is never simply whether an attacker or an accident will ever get past us, but whether we will notice in good time and respond well. That noticing, and the fast, honest report that should follow it, is the ordinary member's part in what the recognised frameworks call Detect and Respond.

You are not expected to be the specialist who investigates an incident or rebuilds a system. That is the work of CIS 310, Cyber Incident Response and Continuity, and of the people appointed to it. Your part is earlier and simpler, and it is the part that decides how much damage is done. You are the sensor and the alarm. You are the one most likely to see the first sign that an account, a device, or a record is not behaving as it should, and you are the one whose quick word lets the right people act before a small problem becomes a large one. An attacker's best friend is the gap between the moment something goes wrong and the moment anyone with authority finds out. This lesson is about closing that gap.

This is the knowledge layer. Reading it will teach you the signs to watch for and the drill to follow, but the habit is built by doing: a reporting drill, knowing your reporting channel by heart, and acting on it under a little pressure are practised and signed off in person where supervision allows. By the end you will be able to list the common signs that an account or device may be compromised; carry out the member's incident drill of recognise, report immediately, do not tamper or pay or hide it, preserve evidence, and follow direction; explain who you report to and why early reporting limits harm; describe how this fits the recognised incident lifecycle; and explain why a fast, blame-free report of a mistake is help to the Army and not a failure.

Key Terms

• Incident: any event that harms, or threatens to harm, the confidentiality, integrity, or availability of our systems, accounts, or information. A clicked phishing link, a locked-out account, a lost device, ransomware, and a misdirected sensitive file are all incidents.
• Indicator of compromise (sign of compromise): an observable sign that something may be wrong, for example a login you did not make, a device suddenly slow and hot, files renamed, or an MFA prompt you did not request.
• Detect (DE): the function in the NIST Cybersecurity Framework that is about spotting events and anomalies in good time. An alert member is a large part of our Detect capability.
• Respond (RS): the framework function about acting on incidents once detected, to limit harm and put things right.
• Incident lifecycle (NIST SP 800-61): the recognised pattern for handling incidents: Prepare, then Detect and Analyse, then Contain, Eradicate, and Recover, then Post-Incident Learning. The specialists run this; the member triggers it.
• Containment: stopping an incident from spreading or doing more harm, for example revoking a compromised account's access or isolating a device. This is a specialist action, not yours to attempt alone.
• Evidence preservation: keeping the device, the message, or the screen as it is so the response team can understand what happened. Tampering can destroy the very traces that explain the incident.
• Ransomware: malicious software that locks or encrypts your files and demands payment to release them. The answer is tested backups and a fast report, never paying.
• No-blame reporting: a culture in which reporting a problem or an honest mistake quickly is treated as help and is expected, not punished. It exists because hidden incidents do far more damage than reported ones.
• Reporting channel: the known, agreed route by which you raise an incident, for example your chain of command and the appointed system or security point of contact, with an out-of-hours fallback.

Why you are the alarm

It is tempting to think that detecting cyber trouble is a technical job done by software and specialists, and that an ordinary member has no part in it. Some of it is technical: there are tools that watch systems and flag anomalies, and CIS 310 covers them. But a great deal of trouble shows up first not in a tool but in a person's ordinary experience of their own account and device. You are the one who knows that you did not just log in from another country, that your laptop was not this slow yesterday, that you never named a file that way, that the message from your colleague does not sound like them. No automated system knows your normal as well as you do, and that knowledge is exactly what makes you a sensor.

This is why the frameworks treat people as part of detection, not as bystanders to it. The NIST Cybersecurity Framework names Detect as one of its core functions, spotting events and anomalies in good time, and members notice many of those anomalies first. The CIS essential cyber-hygiene controls, the baseline for a small force like ours, include basic incident response precisely because they assume that ordinary people will encounter incidents and need a simple, rehearsed way to raise them. Your alertness is not a nice extra; it is a designed-in layer of the defence.

And in our setting it matters more than most. The Principality runs on self-hosted online services, a single sign-on identity service that ties accounts together, and per-user certificates and keys. That design is efficient, but it means a single compromised identity or stolen key can reach further than one stray laptop would in an ordinary office. The flip side is that one alert member who reports fast can have the access cut, the key revoked, and the spread stopped before it travels. For the account and the device in your hands, you are the main part of detection.

The signs that something is wrong

You cannot report what you do not notice, so the first skill is recognising the common signs of compromise. None of these proves an attack by itself; an odd thing can have an innocent cause. But each is a reason to look closer and, if it does not resolve plainly, to report. The rule is simple: when in doubt, treat it as worth a report. A false alarm costs a few minutes; a missed real one can cost a great deal.

Watch your accounts. A sign-in alert or notification for a login you did not make, especially from a strange place, device, or time, is one of the clearest warnings there is. An MFA prompt arriving on your phone when you are not trying to log in means someone with your password is trying to get in and only your refusal is stopping them. Being suddenly locked out of an account that worked yesterday, or finding your password no longer works when you did not change it, can mean an attacker has changed it to lock you out. So can mailbox rules you did not create, sent messages you did not send, or security settings (recovery email, MFA method) quietly altered.

Watch your device. Malware and intrusion often leave the machine behaving oddly: suddenly very slow, hot, or with the battery draining fast for no reason; programs, pop-ups, browser toolbars, or new accounts you did not install or create; settings changed, security software turned off, or updates that will not run; the camera or microphone light coming on by itself; or unusual network activity when you are not doing anything. A device that simply feels wrong, after you have ruled out the ordinary causes, is worth a closer look.

Watch your files and your data. Files that are suddenly locked, encrypted, renamed with a strange extension, or replaced by a ransom note are the signature of ransomware, and that is an emergency report, not a puzzle to solve quietly. Documents missing, moved, or altered when no one should have touched them, or a record that does not match what you know to be true, can mean tampering, the integrity side of security failing. And watch the people around the systems too: a message, email, or call from a colleague that is out of character, asking for money, credentials, or an urgent unusual favour, may mean their account has been taken over and is being used against the rest of us, so verify by a separate known channel before acting, and report it.

   SIGNS OF COMPROMISE  -  a quick checklist

   ACCOUNTS
     [ ] a login or sign-in alert you did NOT make
     [ ] an MFA prompt you did NOT request
     [ ] locked out, or your password suddenly does not work
     [ ] mailbox rules / sent messages / settings you did not set

   DEVICE
     [ ] suddenly slow, hot, or the battery drains fast
     [ ] new apps, pop-ups, toolbars, or accounts you did not add
     [ ] security software off, or updates that will not run
     [ ] camera/mic light on by itself, or odd network activity

   FILES & DATA
     [ ] files locked, encrypted, renamed, or a ransom note
     [ ] documents missing, moved, or altered with no good reason
     [ ] a record that does not match what you know to be true

   PEOPLE
     [ ] a colleague's message asking, oddly, for money or access
     [ ] an "urgent, secret" request that rushes you past your habits

   One tick is enough to look closer.
   If it does not resolve plainly  ->  REPORT.  When in doubt, report.

The member's incident drill

When you recognise a sign, you follow a fixed, short drill. It is deliberately simple, because the moment you most need it is the moment you are likely to be flustered or rushed, and a complicated procedure would be forgotten or skipped. The drill is five steps in order: recognise, report immediately, do not tamper or pay or hide it, preserve evidence, follow direction. It is the ordinary member's version of the recognised incident lifecycle, and it is the part of that lifecycle that is yours.

Recognise. Notice the sign and name it to yourself as a possible incident rather than explaining it away. This is the step the rest depends on, and the hardest, because the easy human response to an odd login or a slow laptop is to assume the innocent cause and move on. Train yourself to pause on the signs above and ask the security question first: could this be someone or something it should not be?

Report immediately. Raise it at once through your reporting channel, before you try to fix it and before you decide for yourself how serious it is. Reporting is the action that brings in the people who can contain the harm, and its value falls fast with every minute of delay. You are not expected to diagnose the incident; you are expected to flag it. Tell them what you saw, when, and what you have and have not done. If you are unsure whether it is "really" an incident, report anyway and let the appointed people judge; that judgement is their job, not yours.

Do not tamper, pay, or hide it. Do not try to investigate, clean up, or fix the system yourself; well-meant tinkering can spread an infection, alert an attacker, or destroy the traces the response team needs. If files are held to ransom, never pay; payment funds the attack, often does not restore the data, and marks us as a target, and our answer is tested backups and a clean rebuild. Above all, never hide an incident or delay reporting because you fear blame. The cover-up is what turns a contained problem into a disaster.

Preserve evidence. Leave things as they are so the response team can understand what happened. As a general rule do not delete the suspicious message, do not wipe or reset the device, and do not "tidy up". If a device may be compromised, the usual safe move is to disconnect it from the network if you can do so simply (unplug the cable, turn off Wi-Fi) to limit spread, but not to power it off, reset it, or run tools on it, because that can erase evidence. Take a photo or screenshot of what you see, an error, a ransom note, a strange login alert, before anything changes, then follow the team's instructions, because the right containment step is their call.

Follow direction. Once you have reported, do as the appointed people instruct, promptly and fully, even if it is inconvenient: change a passphrase, stop using an account or device, hand the device in, confirm what you did. Containment and recovery are coordinated, and freelancing can undo them. Your discipline here, doing your small part exactly and then letting the specialists run theirs, is what makes the whole response work.

   THE MEMBER'S INCIDENT DRILL  -  recognise, report, preserve

      You notice a SIGN of compromise
                |
                v
      1. RECOGNISE  -  name it as a possible incident,
                       do not explain it away
                |
                v
      2. REPORT IMMEDIATELY  -  to your reporting channel,
                       NOW, before you try to fix it
                |
        +-------+----------------------------+
        |                                    |
        v                                    v
      3. DO NOT...                       4. PRESERVE EVIDENCE
         - tamper / investigate / "fix"     - keep the message,
         - pay any ransom                     screen, device as-is
         - HIDE it or delay from fear       - photo/screenshot it
                                            - disconnect network only
                                              if told; do not wipe
        \____________________  ____________________/
                             \/
                             v
      5. FOLLOW DIRECTION  -  do exactly as the appointed
                       people instruct, promptly and fully
                |
                v
      Specialists then CONTAIN, ERADICATE, RECOVER (CIS 310),
      and the team LEARNS and improves for next time.

   Speed is the whole point: early report = less harm.

Who you report to, and why speed wins

A drill is only as good as the channel it feeds, so know your reporting channel before you ever need it. In general you report up your chain of command and to the appointed system or security point of contact for the service involved, by the route your unit has agreed, with a known fallback for out of hours. The exact names and contacts belong in your local instructions and your PACE-style fallback plan, not in a lesson; your task now is to learn them by heart, because an emergency is the wrong time to start hunting for who to tell. If you genuinely cannot reach the first contact, use the fallback and keep trying the chain; the worst report is the one not made because the first number did not answer.

Why such insistence on speed? Because in an incident, harm grows with time, and early reporting is the single biggest thing an ordinary member does to limit it. An attacker with a foothold spends the minutes after they get in spreading: reaching other accounts through our single sign-on, using a stolen identity or key to move further, deleting backups, encrypting more files. Every one of those steps takes time, and a report that comes in early lets the response team cut access, revoke a key or certificate, and isolate a device before the attacker completes them. A late report arrives after the damage is done. The same logic applies to a lost device or a clicked phishing link: reported at once, the access can be revoked and the credentials reset before they are abused; reported a day later, the attacker has had a day.

Speed also protects other people. Your single report lets the team warn others, block a malicious sender, force-reset affected accounts, and watch for the same attack elsewhere, so one member's alert defends the whole force. This is the same principle you met in SIG 220: one disciplined operator's prompt report can protect an entire net. Here the net is our accounts, our systems, and our records, and you are a station on it. Do not sit on a worry, do not wait until you are certain, and do not assume someone else will have noticed. Report early, report to the right channel, and let the people whose job it is decide what it means.

The no-blame rule: reporting fast is help, not failure

There is one more thing standing between a fast report and a slow one, and it is not technical at all. It is fear. People hide incidents, or sit on them for hours hoping they will go away, because they are afraid of looking foolish or being blamed, above all when the incident is partly their own fault: they clicked the link, they reused the password, they lost the device, they sent the file to the wrong person. This fear is the attacker's quietest ally, because the cover-up almost always does more damage than the original mistake. So the Army's rule is deliberate and firm: reporting a problem or an honest mistake quickly is help, and it is exactly what is expected of you. It is not a failure, and it is not punished.

Understand why this is the rule and not mere kindness. Cyber incidents are normal; even careful, well-trained people occasionally get caught, and a force that punished every honest slip would simply teach its members to hide them, which is the worst possible outcome. The member who clicks a phishing link and reports it in the next minute has handed the team the chance to revoke access and reset credentials before harm is done; that member has helped. The member who clicks and says nothing has handed the attacker a head start measured in hours. We far prefer ten honest reports, nine of them false alarms, to one hidden incident, because the false alarms cost minutes and the hidden one can cost the Principality dearly. The discipline being asked of you is the courage to speak up at once, especially when you would rather not.

This no-blame culture is not a licence for carelessness; you are still expected to keep the good habits this course teaches, and persistent or reckless disregard is a separate matter handled separately. But the moment of an incident is not the moment for that conversation. In that moment there is one right action, the fast honest report, and the member who takes it has done their duty well, whatever the mistake that led there. Make the report you are tempted to delay; it is the most useful thing you will do all day.

In Practice: a slow afternoon and a fast report

Private Sera, a systems assistant, is working through routine tasks on her Army account one afternoon when her phone buzzes with an MFA prompt asking her to approve a sign-in. She is not signing in to anything. For a moment the easy explanation tugs at her: maybe a page she left open is reloading, maybe it is nothing, just tap deny and forget it. But she has trained on the signs, and she names it correctly to herself: an MFA prompt she did not request means someone who already has her password is trying to get in, and only her refusal is in the way. She denies the prompt. A few seconds later it comes again, then again. That settles it. This is a possible incident, and she is at the recognise step.

She does not start poking around her account, and she does not change her password and quietly carry on as if nothing happened. She reports immediately, raising it through her unit's known reporting channel to the appointed security point of contact, exactly as she rehearsed: repeated MFA prompts she did not initiate, starting a minute or two ago, all denied, nothing changed yet. While she waits, she preserves what she can: she photographs the prompts on her phone and notes the times, rather than dismissing them and losing the record. She does not pay anything, hide anything, or tamper with the system, and she resists the urge to "just fix it" herself.

The contact acts on the early warning. Because the report came in within minutes, the team can see what a delay would have cost: someone had Sera's reused password from an unrelated breach and was hammering the login, kept out only by MFA and her denials. They reset her password to a fresh unique passphrase, force-sign-out the active sessions, confirm the second factor is sound, and check the account for any rules or settings the attacker might have changed. They follow direction is Sera's last step: she changes the passphrase as instructed, confirms she has reused it nowhere else, and switches to a password manager so she never does. No data was lost, the account held, and the team quietly warns others to watch for the same password-spray attack. Afterwards no one blames Sera for the old reused password that started it; the reused password was a lesson, and the fast honest report was the win. One denied prompt and one prompt report turned an attempted account takeover into a non-event.

Check Your Understanding

1. You receive a notification that your Army account has just signed in from a country you have never visited, and a moment later you cannot log in yourself. List the steps of the member's incident drill in order, and explain why "report immediately" comes before any attempt to fix the problem yourself.
2. A colleague messages you, out of character, with an urgent secret request to send credentials or money. Why might this be a sign of compromise rather than a genuine request, and what should you do before acting and after?
3. Explain the no-blame reporting rule in your own words: why does the Army treat a fast report of your own mistake as help rather than failure, and what does hiding an incident cost compared with reporting it?

Reflection (write a short paragraph): Think of a time you noticed something was not quite right, with a device, an account, or anything else, and talked yourself out of raising it because you were not sure, or because you feared looking foolish or being blamed. Knowing now that early reporting is the single biggest thing you can do to limit harm, and that a fast honest report is treated as help, how would you handle that moment differently, and why is the fear that delays a report so dangerous in our digital setting?

Summary

• No defence is perfect, so the ordinary member's part is to detect and report trouble fast. You know your own normal better than any tool, which makes you the first and best alarm for your accounts, devices, and records, and in our single sign-on, key-based setting a fast report can stop harm spreading far.
• Learn the common signs of compromise: unrequested MFA prompts or logins you did not make; a sudden lockout; a device suddenly slow, hot, or behaving oddly; files locked, encrypted, or renamed; a colleague's out-of-character message. When in doubt, treat it as worth a report.
• Follow the member's incident drill in order: recognise, report immediately, do not tamper or pay or hide it, preserve evidence, follow direction. It is the member's part of the recognised NIST 800-61 incident lifecycle (Prepare, Detect and Analyse, Contain, Eradicate, and Recover, Post-Incident Learning); the specialists run the rest.
• Never pay a ransom and never investigate or clean up alone; preserve the message, screen, and device as they are (photograph them, disconnect from the network only if told), so the response team can do its work.
• Know your reporting channel by heart, your chain of command and the appointed point of contact, with a fallback, because speed is the whole point: early reporting lets access be cut and keys revoked before an attacker finishes, and it protects everyone else too.
• The no-blame rule is deliberate: reporting a problem or honest mistake quickly is help and is expected, never punished, because a hidden incident does far more damage than a reported one. Make the report you are tempted to delay.
• Related study: this leads on to CIS 310 (Cyber Incident Response and Continuity), which handles the specialist response, containment, eradication, recovery, and the post-incident learning. It draws together Lesson 03 (Phishing and Social Engineering), Lesson 04 (Device and Endpoint Security), and Lesson 05 (Safe Data Handling) of this course, and supports SIG 220 (prompt disciplined reporting), HCR 220 (continuity and resilience after an incident), and PME 210 (accurate records and reports). Remember that access follows appointment: the specialists who run the response hold that access by appointment, not by qualification alone.

Crown Copyright © 2026 | Published by Authority of H.R.H. The Prince of Kaharagia