TS-C (NCCT) key terms

The three core goals of information security: confidentiality keeps data from unauthorized readers, integrity keeps it accurate and unaltered, and availability keeps it reachable when legitimate users need it.

Any person, event, or condition with the potential to cause harm to an asset, such as an attacker, malware, a flood, or an accidental deletion.

A weakness in software, configuration, process, or physical setup that a threat could exploit to damage or gain access to an asset.

The likelihood that a threat will exploit a vulnerability combined with the size of the resulting harm, usually judged as impact multiplied by probability.

Giving each user, service, or process only the access needed to do its job and nothing more, which limits the damage from mistakes or a compromised account.

Layering multiple independent controls so that if one fails another still blocks or detects the attack; no single safeguard is trusted on its own.

A safeguard or countermeasure, whether technical, administrative, or physical, put in place to reduce risk by preventing, detecting, or correcting unwanted events.

Sorting information into labeled categories such as public, internal, confidential, and restricted so that handling, storage, and access rules match its sensitivity.

A study that identifies critical business functions and estimates the harm caused when each is disrupted, producing the time and data-loss targets that drive recovery planning.

The maximum acceptable downtime for a process after a disruption, meaning the system must be working again within that many hours or days.

The maximum acceptable amount of data loss measured in time, showing how far back a restore may go before the organization suffers unacceptable harm.

A table linking each requirement to its source, the design element that satisfies it, and the test case that proves it, so nothing requested is silently dropped.

An approved, documented snapshot of the settings for a system or device that later builds and audits are compared against to detect unwanted change.

Reducing a system's attack surface by removing unneeded services and accounts, closing unused ports, and applying secure settings before it goes into production.

A controlled process for requesting, reviewing, approving, scheduling, and documenting changes so that modifications do not cause unplanned outages or security gaps.

A prepared way to return a system to its previous known-good state if a change fails, including backups, saved configurations, and the steps to restore them.

A step-by-step operational guide for a routine task or a known incident, written so any qualified on-call staff member can follow it consistently under pressure.

A contract stating expected service levels such as uptime, response time, and support hours, plus how performance is measured and what happens when targets are missed.

Security Information and Event Management: a platform that collects logs from many sources, correlates events, and raises alerts for analysts to investigate.

Intrusion Detection and Prevention Systems watch network or host traffic for malicious patterns; detection-only sensors raise alerts, while prevention devices also block the traffic inline.

Automated probing of systems and applications against known weakness signatures to produce a prioritized list of findings that teams can remediate.

An authorized, simulated attack that chains real weaknesses together to show what an adversary could actually achieve, going beyond what automated scanners report.

A documented set of roles, communication paths, and phases (prepare, identify, contain, eradicate, recover, learn) for handling security incidents consistently and quickly.

A structured investigation that keeps asking why a fault occurred until the underlying process or design flaw is found, rather than stopping at the first visible symptom.

The defined order of people and time limits for raising an unresolved issue to more senior or specialized support so problems do not stall with one engineer.

The gradual divergence of a system's actual settings from its approved baseline, often caused by manual fixes and hotfixes, which creates unpredictable behavior and hidden risk.

Copies of data and system state kept separately so that lost or corrupted information can be recovered, together with the tested procedures for putting those copies back.

Documented procedures and resources for restoring critical systems and data, either at an alternate site or from backups, after a major outage or destructive event.

Logon that requires two or more different evidence types, something you know, have, or are, so a stolen password alone is not enough to get in.

Assigning permissions to job roles rather than to individuals, then placing users in roles, which simplifies administration and keeps access consistent as staff change.

Protecting stored data by encoding it on disk so that anyone who obtains the physical drive or a stolen backup cannot read it without the correct key.

A screened network segment between the internet and the internal network that hosts public-facing services, limiting the damage if one of those services is compromised.

Rewriting IP addresses as packets cross a boundary, which lets many internal hosts share public addresses and hides internal addressing from outside observers.

A logically separated network segment created on shared switching hardware, used to keep traffic groups apart and to apply different security policy to each.

A maintained record of hardware, software, data, and their owners, which is the starting point for patching, monitoring, and knowing what needs protection.

A documented, unbroken record of who handled evidence, when, and where, required to keep digital evidence admissible and credible during investigations.

A design principle that trusts no user or device by default and verifies every request using identity, device health, and context before granting access to resources.

A system that checks a device's identity and compliance, such as patch level and antivirus state, before allowing that device onto the network.

Formal testing against agreed requirements, performed before handover, to confirm that a delivered system works as specified and is fit for its intended use.