Security incidents, evidence and privacy duties

A reception laptop shows a full-screen note demanding payment to release its files, and the user has already rebooted it twice. The next five minutes decide whether anyone can learn how it happened, because a wipe, a reboot or a power-off can erase the only evidence, and the clock on reporting it has already started.

This is where the help desk’s job changes shape. For an ordinary fault you fix the machine and move on; for a security incident you protect what happened, report it on the right path, and hand the investigation to people who have the authority and the tools for it. This lesson is about that handover: recognising a security incident, keeping its evidence and its chain of custody intact, handling card, health and personal data correctly, and meeting India’s reporting clocks.

A security incident is for the security team to judge

An ordinary service incidentincident: An unplanned interruption of a service, or a drop in its quality, that stops people working as they should. It is judged on how quickly the service becomes usable again, not on whether the cause is understood. More in “Incidents, problems and major incidents” is judged on one thing: how soon the service is usable again (that is the service-desk side, covered in incidents, problems and majors). A security incidentAn event where someone may have gained access they should not have, or where data may have been exposed, taken or altered, so the response turns on what spread and what must be reported. is different because someone may have gained access they should not have, so the questions become how far it spread, what was taken and what must be told to whom. Unauthorised sign-ins, malware, a lost device with company data, an account sending spam and prohibited content on a disk are all security incidents, whatever else they look like at first.

NIST sets out how organisations handle these. Its guidance, SP 800-61 Rev. 3, places incident response inside the NIST Cybersecurity Framework 2.0 and its Detect, Respond and Recover work, rather than treating it as a job apart. At the help desk, that work has a small, firm shape: recognise the sign, report it on the agreed path, and contain it within policy. The desk does not investigate alone, because opening files, running its own tools or questioning people can change or destroy the very evidence the investigation needs.

Reporting early is the step that matters most. It costs a phone call or a ticket to the security team or the incident manager named in the policy, and it is what turns a problem one technician is carrying into one the right people own.

Protect the evidence before anyone decides what to keep

Write down what you see as it happens, with the time and its UTC offset on every line, the way an ISO 8601 timestampISO 8601 timestamp: A date and time written in the international ISO 8601 order, from the largest unit to the smallest, with a UTC offset after the time, as in a time written 14:05+05:30, or a trailing Z for UTC. More in “Ticket notes and handoffs people can use” records a moment. A note written from memory an hour later is weaker evidence than one written at the time, and the time you first noticed the incident is itself evidence, so it belongs in the first line.

Then leave the machine as it is. Do not wipe, reimage, run a cleanup or power it off to tidy up. RFC 3227, the long-standing guide to collecting evidence, puts it plainly: “Don’t shutdown until you’ve completed evidence collection.” To stop malware spreading, CISA’s #StopRansomware Guide says that when several systems or subnets look affected the network is taken offline at the switch level, and that when that cannot be done straight away the affected devices are unplugged from the cable or taken off Wi-Fi. It keeps powering a device down for when you cannot disconnect it another way, and warns that powering it down loses the evidence held in memory. So the help desk’s safe move is almost always to disconnect, not to switch off.

When evidence is collected, it is taken in order of how quickly it disappears. RFC 3227 calls this the order of volatilityThe order in which digital evidence is collected, from the most fleeting to the most stable: memory and live connections first, then temporary files, the disk, remote logs, and the most stable records last.: collect the most fleeting first.

The desk rarely collects any of this itself; the security team does. The desk’s job is to make that collection possible, which means disconnecting rather than powering off, and keeping every log.

A chain of custody records who held the evidence

Once a device becomes evidence, every move it makes is written down. The chain of custodyThe record of who found, held, handled and transferred a piece of evidence, and when, so its integrity can be shown and no unexplained gap is left. is that record, and the CompTIA A+ objectives list it alongside informing management or law enforcement, taking a copy of the drive, keeping documentation and following the order of volatility. RFC 3227 says the record must show where, when and by whom the evidence was discovered and collected, who handled or examined it, who held it and how it was stored, and how each change of hands happened.

Two habits make the record trustworthy. Work on a copy, not the original: disk imagingdisk imaging: Copying a whole drive, sector by sector, to a file or another drive, so that recovery work runs on the copy instead of the original. More in “Restore files and recover data safely” copies the drive sector by sector so the investigation runs on the copy. And record a hash of the evidence when it is collected, the way a hash manifesthash manifest: A list of files with the hash of each, written at backup time, against which restored copies are checked. Lines of the form hash, two spaces, file name are what sha256sum -c reads. More in “Restore files and recover data safely” fixes a file’s fingerprint, so that any later change shows up at once.

A custody log fails in a few predictable ways: a time that runs backwards, a handover with no receiver or no stated purpose, or a hash that no longer matches the one taken at collection. The program below reads two invented logs, one with three such mistakes and one with them put right, and prints every problem it finds:

"""Check an invented chain-of-custody log for the mistakes that break it.

A custody log records every time a piece of evidence changes hands: the time
with its UTC offset, who gave it, who received it, why, and the hash of the
evidence recorded at collection. This program reads two logs (both invented for
this lesson, with made-up names) and prints every problem it finds:

  * a time that goes backwards from the handover before it,
  * a handover with no receiver, or no stated purpose,
  * a hash that differs from the one recorded at the first handover.

It reads no clock and talks to no network, so its output is the same every run.
"""


def utc_minutes(stamp):
    """Turn "day 1, 09:14+05:30" into whole minutes on a single UTC scale."""
    day_label, clock = stamp.split(",")
    day = int(day_label.strip().split()[1])
    clock = clock.strip()
    if "+" in clock:
        hhmm, offset = clock.split("+")
        sign = 1
    else:
        hhmm, offset = clock.split("-")
        sign = -1
    hour, minute = hhmm.split(":")
    off_hour, off_minute = offset.split(":")
    local = day * 1440 + int(hour) * 60 + int(minute)
    offset_minutes = sign * (int(off_hour) * 60 + int(off_minute))
    return local - offset_minutes


def custody_errors(log):
    """Return the problems in the log, in reading order, as plain sentences."""
    errors = []
    first_hash = log[0]["hash"] if log else ""
    previous = None
    for index, handover in enumerate(log):
        moment = utc_minutes(handover["time"])
        if previous is not None and moment < previous:
            errors.append("entry " + str(index + 1) + ": time goes backwards")
        if not handover["to"]:
            errors.append("entry " + str(index + 1) + ": no receiver")
        if not handover["purpose"]:
            errors.append("entry " + str(index + 1) + ": no purpose")
        if handover["hash"] != first_hash:
            errors.append("entry " + str(index + 1) + ": hash does not match the first record")
        previous = moment
    return errors


def report(title, log):
    print(title)
    problems = custody_errors(log)
    if not problems:
        print("  no problems found")
    else:
        for line in problems:
            print("  " + line)
    print("")


# A sample log with three mistakes, invented for this lesson. The evidence is a
# laptop collected at a help desk; every name is made up.
flawed_log = [
    {"time": "day 1, 09:14+05:30", "from": "reception (Asha)", "to": "technician (Ravi)",
     "purpose": "collected from the user", "hash": "3f1a9c"},
    {"time": "day 1, 15:02+05:30", "from": "technician (Ravi)", "to": "evidence store",
     "purpose": "locked for the night", "hash": "3f1a9c"},
    {"time": "day 1, 14:30+05:30", "from": "evidence store", "to": "analyst (Meera)",
     "purpose": "handed over for imaging", "hash": "3f1a9c"},
    {"time": "day 2, 10:05+05:30", "from": "analyst (Meera)", "to": "",
     "purpose": "imaged, original locked away", "hash": "3f1a9c"},
    {"time": "day 2, 16:40+05:30", "from": "evidence store", "to": "technician (Ravi)",
     "purpose": "released after analysis", "hash": "7c2e4b"},
]

# The same log once the three mistakes are put right.
fixed_log = [
    {"time": "day 1, 09:14+05:30", "from": "reception (Asha)", "to": "technician (Ravi)",
     "purpose": "collected from the user", "hash": "3f1a9c"},
    {"time": "day 1, 15:02+05:30", "from": "technician (Ravi)", "to": "evidence store",
     "purpose": "locked for the night", "hash": "3f1a9c"},
    {"time": "day 1, 15:30+05:30", "from": "evidence store", "to": "analyst (Meera)",
     "purpose": "handed over for imaging", "hash": "3f1a9c"},
    {"time": "day 2, 10:05+05:30", "from": "analyst (Meera)", "to": "evidence store",
     "purpose": "imaged, original locked away", "hash": "3f1a9c"},
    {"time": "day 2, 16:40+05:30", "from": "evidence store", "to": "technician (Ravi)",
     "purpose": "released after analysis", "hash": "3f1a9c"},
]

report("Flawed log:", flawed_log)
report("Fixed log:", fixed_log)

Flawed log:
  entry 3: time goes backwards
  entry 4: no receiver
  entry 5: hash does not match the first record

Fixed log:
  no problems found

The flawed log trips three checks: entry 3 is timestamped before entry 2, entry 4 names no receiver, and entry 5 carries a hash that differs from the one recorded at the first handover. The fixed log reports no problems, because each handover now moves forward in time, names a giver and a receiver, and keeps the same hash throughout. One fault this program does not look for is a gap: a handover that starts with someone other than the last receiver, which leaves a stretch of time when nobody can say who held the laptop. The exercise at the end of the lesson adds that check.

Prohibited content means stop, secure and escalate

Sometimes a technician fixing something else finds material on a device that looks illegal. The rule here is short and it never changes: stop. Do not open it further, do not copy or forward it, and do not show it to a colleague to check. Leave the device as it is, secure it, and escalate exactly as the acceptable use policyA policy that sets out what people may and may not do with an organisation's devices, accounts and network, and what happens when the rule is broken. says, to the security team, to HR or to legal. Gathering more of it yourself, even to be sure, can break the law and destroy the handling record.

The move splits cleanly into what to do and what never to do:

Keep the written note to the plain facts: what you were doing, what you saw at a high level, and the time. The people you escalate to decide everything else.

Regulated and personal data need more than ordinary care

Some data carries duties of its own, and a ticket can quietly break them. Three kinds come up most at the desk.

Card data is governed by the PCI Data Security Standard from the PCI Security Standards Council, which protects cardholder dataThe primary account number on a payment card, with data such as the cardholder name and expiry date. and sensitive authentication dataThe card verification code, whether printed on the card or held in its magnetic stripe or chip data, and the PIN: the values the card's issuer checks when it authorises a payment.. The standard does not allow sensitive authentication data, such as the card security code, to be stored after a payment is authorised, and it asks for any card number that is stored to be rendered unreadable, by truncation or strong encryption for example. A ticket keeps text exactly as it was typed, so a full card number or a security code never goes into one. Health data is handled under the sector rules that apply where you work, and is shared only with those who must see it. Personal data in India comes under the Digital Personal Data Protection Act, 2023India's Digital Personal Data Protection Act, 2023, the law that governs how personal data is processed, with duties on the organisation that decides why and how it is used., under which a personal data breachPersonal data processed without authority, or accidentally disclosed, shared, altered, destroyed or made unreachable, in a way that harms its confidentiality, integrity or availability. The Act asks the organisation to tell the regulator and each person affected. must be told to the regulator and to the people affected.

What this means in a ticket is the same each time: keep only what the ticket needs, and keep the rest out of the notes.

That is data minimisationdata minimisation: Collecting and sharing only the data a task needs, and no more. More in “Use AI assistants safely at the help desk” and redactionredaction: Permanently removing private information from a document or image before sharing it, by cropping it out or covering it with a solid block, rather than blurring it or hiding it under a layer that can be undone. More in “Ticket notes and handoffs people can use” doing their ordinary work: a screenshot with a full card number or an identity number on it is itself a small data exposure, so it is masked before it goes into a ticket.

Noticing the incident starts the reporting clocks in India

A security incident in India starts two kinds of clock, and the desk’s part is to protect the evidence and the logs that let the organisation meet them.

The clocks run as phases from the moment of noticing, never from a calendar date:

Practise: find the faults in a custody log

The exercise gives you a handover log and asks you to return its faults in reading order: a time that runs backwards, a gap where a handover starts with someone other than the last receiver, a handover missing its receiver or purpose, and a hash that no longer matches the first record. The sample tests check the edges, such as two handovers in the same minute and a missing hash against a changed one:

def custody_errors(log):
    """Return the faults in the log, in reading order, as short strings."""
    return []

from custody_errors import custody_errors

CLEAN = [
    {"minute": 554, "from": "reception", "to": "technician", "purpose": "collected", "hash": "3f1a9c"},
    {"minute": 902, "from": "technician", "to": "evidence store", "purpose": "locked overnight", "hash": "3f1a9c"},
    {"minute": 1770, "from": "evidence store", "to": "analyst", "purpose": "imaging", "hash": "3f1a9c"},
]


def changed(index, **fields):
    """A copy of the clean log with one handover's fields changed."""
    log = [dict(handover) for handover in CLEAN]
    log[index].update(fields)
    return log


def test_clean_log_has_no_faults():
    assert custody_errors(CLEAN) == []


def test_time_going_backwards_is_flagged():
    assert custody_errors(changed(2, minute=800)) == ["entry 3: time goes backwards"]


def test_same_minute_is_not_backwards():
    assert custody_errors(changed(2, minute=902)) == []


def test_one_minute_earlier_is_backwards():
    assert custody_errors(changed(2, minute=901)) == ["entry 3: time goes backwards"]


def test_gap_in_custody_is_flagged():
    # Entry 2 gave the evidence to the evidence store, but entry 3 says the technician handed it on.
    assert custody_errors(changed(2, **{"from": "technician"})) == ["entry 3: gap in custody"]


def test_missing_receiver_is_flagged():
    assert custody_errors(changed(1, to="")) == ["entry 2: no receiver"]


def test_after_a_missing_receiver_is_not_a_gap():
    # Entry 2 names no receiver, so entry 3 cannot be compared with it: only "no receiver" is reported.
    log = changed(1, to="")
    log[2]["from"] = "someone else"
    assert custody_errors(log) == ["entry 2: no receiver"]


def test_missing_purpose_is_flagged():
    assert custody_errors(changed(1, purpose="")) == ["entry 2: no purpose"]


def test_changed_hash_is_flagged():
    assert custody_errors(changed(2, hash="7c2e4b")) == ["entry 3: hash does not match the first record"]


def test_missing_hash_is_flagged():
    assert custody_errors(changed(2, hash="")) == ["entry 3: hash does not match the first record"]


def test_first_entry_is_never_backwards_or_a_gap():
    assert custody_errors([dict(CLEAN[0], minute=5)]) == []
    assert custody_errors([dict(CLEAN[0], **{"from": "anyone"})] + CLEAN[1:]) == []


def test_one_handover_reports_every_fault_in_order():
    log = changed(2, minute=800, to="", hash="7c2e4b", **{"from": "technician"})
    assert custody_errors(log) == [
        "entry 3: time goes backwards",
        "entry 3: gap in custody",
        "entry 3: no receiver",
        "entry 3: hash does not match the first record",
    ]

Then test yourself on the six ideas of this lesson, from recognising a security incident to the reporting clocks:

Interview questions

Warm-up (fresher to 2–5 years): why is memory collected before the disk?

Because memory is the most fragile evidence there is. Memory holds the running programs, the open network connections and any traces a piece of malware keeps nowhere else, and all of it is gone the moment the power goes, while the disk survives a clean shutdown. RFC 3227’s order of volatility ranks evidence by how quickly it disappears and says to collect the most fleeting first, so memory comes before temporary files, and both come before the disk. At the help desk this is why the safe move is to disconnect a machine rather than switch it off: switching off throws away the memory the investigation may need. The desk rarely collects memory itself; its job is to keep that choice open for the security team.

The next two drop you into a decision under pressure, where the easy move is the wrong one. Settle on what you would do first, then open each to see what a strong answer covers and where a weak one stops:

Key takeaways

• A security incident is judged on access, spread and what must be told, not just on getting the service back; the desk recognises it, reports it and contains it within policy, and hands the investigation over.
• Protect evidence by writing times as they happen, disconnecting rather than powering off, and leaving the device untouched; when it is collected, the most volatile data is taken first.
• A chain of custody records who found, held, handled and transferred the evidence, with no gap between holders; work on a copy of the drive and fix a hash at collection so any later change shows.
• Prohibited content means stop, secure and escalate on the policy’s path, and never open, copy or investigate it.
• Keep card numbers, security codes and identity numbers out of tickets, and share regulated data only with those who must see it.
• In India, a listed incident is reported to CERT-In within 6 hours of noticing it, logs are kept for a rolling 180 days within the country, and, as the DPDP Rules’ phased duties take effect, a personal data breach is told to the regulator and, without delay, to each person affected.