Cybersecurity Basics

Cybersecurity Terminology for Beginners

Learn cybersecurity terminology for beginners with plain definitions, safe examples, key distinctions, India-aware scam context, and a searchable glossary.

Text-free abstract knowledge index with connected illuminated nodes for identity, scams, data, networks, devices, response, and governance around a protected central reference system

Cybersecurity terminology is the set of words used to describe digital assets, identities, threats, weaknesses, controls, data, networks, incidents, and recovery. Use this page as a learning aid and reference index, not as legal advice or a guarantee of safety. Follow Foundations → Identity → Scams → Data → Devices & networks → Detection & response → Governance & software, or search and browse A–Z.

Foundations and risk

Build a shared vocabulary for assets, possible harm, weaknesses, impact, events, and the people or groups involved.

Cybersecurity

Also known as: cyber security

Cybersecurity is the practice of protecting digital assets, identities, devices, networks, services, and data from harmful or unauthorised activity.

Example: A student protects a college portal account, laptop, and coursework by using supported updates, careful sign-in, and a recovery plan.
Do not confuse with: Do not confuse cybersecurity with a single product, a promise of perfect prevention, or a guarantee that no incident can occur.
Why it matters: It provides the broad frame that connects identity, threats, controls, data, response, and recovery.
Defensive next step: Start by listing an important account, device, service, or data set and its owner so the next decision has a clear boundary.
Context: This is a beginner, defensive description rather than a legal, compliance, or sector-specific definition.

Reviewed: 2026-09-29

Asset

Also known as: digital asset

An asset is something of value that an individual or organisation wants to protect, such as data, an account, a device, or a service.

Example: A small business identifies its payment account, supplier invoices, shared cloud folder, and work laptop as assets.
Do not confuse with: Do not confuse an asset with a threat or vulnerability; an asset is what may be affected, not the possible harm or weakness.
Why it matters: Naming assets helps an owner set priorities and identify what a control or recovery copy should protect.
Defensive next step: Write down the asset, owner, purpose, and most important consequence if it becomes unavailable or exposed.
Context: NIST CSF uses asset and organisational context within a risk-management model; the practical list here is an adaptation.

Reviewed: 2026-09-29

Threat (None)

Also known as: threat source

A threat is a circumstance, event, or source that could cause an adverse effect to an asset or activity.

Example: An unexpected caller asking for a payment approval can represent a possible social-engineering threat to a business account.
Do not confuse with: Do not confuse a threat with a vulnerability or risk: a threat is a possible source or event, a vulnerability is a weakness, and risk considers possible impact and likelihood; none alone proves an incident.
Why it matters: Separating the possible source from the weakness and consequence helps an owner choose a proportionate response.
Defensive next step: Record what could happen, who or what could cause it, and which asset could be affected without assuming that harm has occurred.
Context: The exact scope of threat varies by glossary or risk method, so this entry uses a bounded NIST-style context.

Reviewed: 2026-09-29

Vulnerability

Also known as: weakness

A vulnerability is a weakness or condition that could be used or triggered to cause harm to an asset or system.

Example: An unsupported application with a known configuration weakness may be recorded as a vulnerability for the device owner to address.
Do not confuse with: Do not confuse a vulnerability with a threat or risk: a weakness is not itself a harmful event, and it does not prove that an incident occurred.
Why it matters: It helps an owner turn a general concern into a specific condition that can be corrected, isolated, monitored, or accepted with context.
Defensive next step: Ask the authorised owner to confirm the affected asset, support status, exposure, and safe remediation path.
Context: Definitions and handling can differ by standard, disclosure policy, and sector; do not infer exploitability or legal status from the label alone.

Reviewed: 2026-09-29

Risk

Also known as: cyber risk

Cybersecurity risk is the possibility that a threat or other event will lead to harm, considered with factors such as impact and likelihood.

Example: A small shop weighs the possible effect of losing access to its payment account against the account’s exposure and available recovery options.
Do not confuse with: Do not confuse risk with a threat, vulnerability, or incident: risk considers possible outcomes and likelihood, while none alone proves that an adverse event happened.
Why it matters: It helps people prioritise limited time and resources rather than treating every issue as equally urgent.
Defensive next step: Describe the asset, possible event, impact, likelihood factors, existing controls, and remaining uncertainty for an authorised decision.
Context: Risk formulations are method-specific and context-dependent; this is a plain-language NIST-oriented explanation, not a numeric score.

Reviewed: 2026-09-29

Incident

Also known as: cyber incident

A cybersecurity incident is a real or suspected adverse event that affects or may affect the confidentiality, integrity, or availability of information or systems.

Example: A business records an unexpected account change, preserves the visible details, and contacts its authorised provider or response lead for assessment.
Do not confuse with: Do not confuse an incident with cybercrime: an incident describes a real or suspected adverse cyber event, while cybercrime is a law-enforcement or legal concept requiring appropriate context and determination.
Why it matters: A clear incident label can trigger safe preservation, containment, communication, and recovery without jumping to unsupported conclusions.
Defensive next step: Record time, affected service, observable facts, and authorised contacts, and avoid deleting evidence or making a legal conclusion.
Context: Institutional reporting directions and individual victim or police complaint routes are different contexts; CERT-In directions do not create a universal individual duty.

Reviewed: 2026-09-29

Cybercrime

Also known as: cyber crime

Cybercrime is a term used for criminal activity involving computers, networks, digital services, or data, subject to the relevant legal and law-enforcement context.

Example: A person who suspects an online financial loss keeps transaction details and uses an appropriate victim or police complaint route rather than trying to investigate independently.
Do not confuse with: Do not confuse cybercrime with an incident: an incident may be real or suspected without establishing a crime, offender, or legal determination.
Why it matters: The distinction helps readers preserve evidence and seek the right support without making accusations from a technical warning alone.
Defensive next step: Preserve relevant records and use an authorised service, provider, victim-support, or police channel appropriate to the situation.
Context: Legal definitions, jurisdiction, and reporting pathways vary; this entry is not legal advice and does not determine whether conduct is criminal.

Reviewed: 2026-09-29

Identity and access

Explain who or what is being represented, how identity is checked, and how permissions and sessions are limited.

Identity

Also known as: digital identity

An identity is the representation of a person, organisation, device, or service used to distinguish it in a digital interaction.

Example: A college portal associates a student’s account with permitted coursework and recovery details.
Do not confuse with: Do not confuse an identity with authentication or authorization: identity is the represented subject, authentication checks a claim, and authorization decides allowed actions.
Why it matters: Clear identity ownership supports appropriate access, recovery, accountability, and removal of stale accounts.
Defensive next step: Confirm who owns the account or device and keep recovery details current through the authorised service.
Context: Identity models and assurance levels vary by service and standard; this entry avoids treating an account label as proof of a person’s real-world identity.

Reviewed: 2026-09-29

Authentication (AuthN)

Also known as: authn, login verification

Authentication is the process of checking a claim that a person, device, or service is the identity it presents.

Example: A student signs in to a learning portal and the service checks the account’s password and additional approved factor.
Do not confuse with: Do not confuse authentication with authorization: authentication asks who or what you are, while authorization asks what that identity may do.
Why it matters: It helps a service make an identity decision before granting a session or access request.
Defensive next step: Use the service’s supported authentication method, protect recovery options, and review unusual sign-in notices.
Context: Methods and assurance requirements vary by system and identity standard; successful authentication does not grant every permission.

Reviewed: 2026-09-29

Authorization (AuthZ)

Also known as: authz, access permission

Authorization is the decision about which actions or resources an authenticated identity may access.

Example: A staff member can view a supplier invoice folder but cannot change account-wide security settings.
Do not confuse with: Do not confuse authorization with authentication: signing in establishes an identity claim, while authorization limits what that identity may do.
Why it matters: It limits unnecessary access and reduces the impact of an account being misused or misconfigured.
Defensive next step: Ask the authorised owner to review role and resource permissions, remove unused access, and keep administrative actions separate where feasible.
Context: Access decisions depend on application, organisation, and resource policy; a successful login is not unlimited authority.

Reviewed: 2026-09-29

Multi-factor authentication (MFA)

Also known as: mfa, 2FA, two-factor authentication

Multi-factor authentication uses two or more different factor types to check an identity during access.

Example: A cloud account asks for a password and an approved authenticator or security key when a student signs in.
Do not confuse with: Do not confuse MFA with a guarantee or with two copies of the same factor; MFA can reduce the value of one stolen password but does not remove every phishing, recovery, device, or session risk.
Why it matters: It adds another check when one credential is exposed or guessed.
Defensive next step: Enable the service’s supported MFA, protect backup methods, and verify recovery contacts through the official account settings.
Context: Factor choices and assurance vary by service, and some legacy or recovery paths may not provide the same protection.

Reviewed: 2026-09-29

Identity proofing

Also known as: identity verification

Identity proofing is the process of establishing that an applicant is associated with a claimed real-world identity before an identity service issues or binds credentials.

Example: A regulated service follows its documented enrolment process to check an applicant’s identity before activating an account.
Do not confuse with: Do not confuse identity proofing with routine authentication: proofing establishes an account-to-person relationship, while authentication checks a later access claim.
Why it matters: It helps a service decide how much confidence to place in an identity during enrolment and recovery.
Defensive next step: Use only the service’s official proofing process and do not send identity documents to an unexpected contact.
Context: NIST assurance levels and evidence requirements are context-specific U.S. technical guidance, not Indian legal advice.

Reviewed: 2026-09-29

Session

Also known as: session state, session token

A session is the period and state in which a service maintains an authenticated interaction with a user, device, or client.

Example: After a student signs in, the college portal maintains a session until it expires or the student signs out.
Do not confuse with: Do not confuse a session with authentication or authorization: authentication starts an identity check, authorization sets permissions, and a session carries an ongoing interaction subject to those decisions.
Why it matters: Session handling affects how long access remains active and how a service can end or review it.
Defensive next step: Sign out of shared devices, review active sessions, and use the service’s official revoke or reset controls when a session is unexpected.
Context: Session identifiers and lifecycle rules differ by application; this entry does not prescribe implementation details.

Reviewed: 2026-09-29

Least privilege

Also known as: minimum necessary access

Least privilege is the practice of giving an identity, process, or device only the access needed for its current task.

Example: A student account can use course resources without receiving router administration rights.
Do not confuse with: Do not confuse least privilege with denying all access or with authentication; it limits authorised permissions after identity decisions.
Why it matters: Narrow permissions can reduce accidental changes and limit the consequences of a misused account.
Defensive next step: Review roles and remove permissions that are no longer needed, using an authorised change process.
Context: The practical scope depends on the system and role; least privilege is a design principle, not a guarantee.

Reviewed: 2026-09-29

Scams and harmful code

Recognize deceptive contact and harmful software at a high level, with safe pause-and-verify responses.

Phishing

Also known as: phishing attack

Phishing is deceptive social engineering that tries to influence a person to reveal information, open content, transfer value, or take another unsafe action.

Example: A person receives an unexpected message about a payment or account and pauses to verify it through a separately found official channel.
Do not confuse with: Do not confuse phishing with spam: phishing is deceptive social engineering, while spam is unwanted communication and is not automatically deceptive.
Why it matters: Recognition and a safe pause can reduce the chance that pressure turns into a credential, payment, or data loss.
Defensive next step: Do not use the message’s links or contact details; verify independently, report through an approved channel, and delete or quarantine it as appropriate.
Context: The term covers many channels and examples; this entry intentionally avoids reproducing lure wording or testing suspicious content.

Reviewed: 2026-09-29

Smishing

Also known as: SMS phishing, text-message phishing

Smishing is phishing delivered through SMS or similar text messaging.

Example: An unexpected courier, KYC, or telecom message asks a reader to act, so the reader opens the official app independently instead of following the message.
Do not confuse with: Do not confuse smishing with every unwanted text or with vishing; smishing is deceptive text-based social engineering, while vishing uses voice.
Why it matters: It helps readers recognise that a familiar phone channel does not make a request authentic.
Defensive next step: Pause, avoid message links, verify with an independently found provider contact, and report the message through an approved route.
Context: Channel labels vary across guidance; the safe response is recognition and verification, not replying or experimenting.

Reviewed: 2026-09-29

Vishing

Also known as: voice phishing, phone phishing

Vishing is phishing conducted through a voice call or voice message.

Example: A caller claiming to represent a bank asks for an urgent approval, so the account holder ends the call and contacts the bank using a known number.
Do not confuse with: Do not confuse vishing with a normal service call or with smishing; vishing uses deceptive voice contact, while smishing uses text.
Why it matters: It highlights that caller confidence or a familiar voice is not independent proof of identity.
Defensive next step: End an unexpected high-pressure call, do not disclose secrets, and verify through a separately sourced official channel.
Context: Voice, voicemail, and messaging boundaries can vary; no realistic lure or impersonation script is needed to learn the concept.

Reviewed: 2026-09-29

Malware

Also known as: malicious software, harmful software

Malware is software or code designed or used to perform harmful, unauthorised, or unwanted actions.

Example: A device owner uses a trusted update and support process after security software reports a suspicious application, rather than opening or analysing it personally.
Do not confuse with: Do not confuse malware with a virus: malware is the broad harmful-software category, while a virus is one type or example.
Why it matters: The broad label helps a beginner discuss harmful software without assuming a particular mechanism or outcome.
Defensive next step: Keep software updated, use trusted sources, maintain protected backups, and contact authorised support when a device behaves unexpectedly.
Context: The exact boundary of malware varies by glossary; this entry stays at the high-level defensive meaning.

Reviewed: 2026-09-29

Virus

Also known as: computer virus

A computer virus is a type of malicious code that can replicate or spread by attaching to or altering other content or programs.

Example: A security tool identifies a suspicious file as a possible virus, so the user follows the device owner’s approved isolation and support process.
Do not confuse with: Do not confuse a virus with malware as a whole: a virus is one type or example of malware, not the entire category.
Why it matters: The distinction prevents a broad device concern from being described too narrowly or with unsupported technical certainty.
Defensive next step: Do not open or share the suspicious file; use updated protective software and authorised support for assessment.
Context: Usage differs across popular and technical glossaries, so this entry uses a bounded example-level description.

Reviewed: 2026-09-29

Ransomware

Also known as: ransom malware

Ransomware is malware that restricts access to data or systems and demands some form of payment or action.

Example: A small business notices that shared files are unavailable and follows its prepared response plan, preserving details and contacting authorised support rather than paying or experimenting.
Do not confuse with: Do not confuse ransomware with every outage or with a backup: ransomware is a harmful-software scenario, while a backup is a recovery resource.
Why it matters: Prepared access controls, updates, response roles, and protected recovery copies can help reduce disruption and support safer decisions.
Defensive next step: Keep independent protected backups, restrict unnecessary access, and use an authorised incident-response path if files become unexpectedly unavailable.
Context: Outcomes, payment decisions, and recovery vary; this entry makes no promise about restoration, attribution, or law-enforcement results.

Reviewed: 2026-09-29

Data and cryptography

Show how confidentiality, integrity, encryption, hashing, and tokenization describe different ways of protecting or representing data.

Encryption

Also known as: encrypted data

Encryption transforms data so that it is not readable in the intended way without the appropriate key or secret.

Example: A remote worker uses a service with HTTPS so data is protected on the relevant application connection while travelling to the service.
Do not confuse with: Do not confuse encryption with hashing: encryption is designed to be reversible with a key, while hashing creates a fixed representation not intended for decryption; encryption also does not prove that a destination is trustworthy.
Why it matters: It can reduce exposure of data on a supported path or storage system when keys and endpoints are handled appropriately.
Defensive next step: Use the service’s supported encryption and protect keys or recovery secrets through the authorised owner.
Context: Algorithms, key management, endpoints, and context matter; encryption is not a guarantee of confidentiality everywhere.

Reviewed: 2026-09-29

Hashing

Also known as: hash function

Hashing applies a one-way-style function to data to produce a fixed-length representation used for comparison or integrity checks.

Example: A service compares a supplied file’s hash with a published value to check whether the file changed during transfer.
Do not confuse with: Do not confuse hashing with encryption: a hash is not intended to be decrypted, while encryption is designed for key-based recovery of readable data.
Why it matters: It can help detect changes or compare values without treating the representation as the original data.
Defensive next step: Use the hash method and comparison process specified by the trusted service, and do not assume a match proves source authenticity.
Context: Security properties depend on the algorithm, inputs, storage, and comparison context; this is not a password-storage implementation guide.

Reviewed: 2026-09-29

Hash value

Also known as: digest, file hash

A hash value is the fixed representation produced when data is processed by a hashing function.

Example: A victim-support service asks for a file hash as one piece of information to help identify the exact file being discussed.
Do not confuse with: Do not confuse a hash value with encrypted content or proof that a file is safe; it supports comparison but is not a readable backup or authenticity guarantee.
Why it matters: A stable comparison value can help people discuss the same file or check whether data changed.
Defensive next step: Obtain a hash through trusted software or support instructions and share it only with an authorised recipient.
Context: The Indian cybercrime FAQ uses hash-value explanations in a reporting context; requirements and handling may differ.

Reviewed: 2026-09-29

Tokenization

Also known as: tokenisation

Tokenization replaces a sensitive data element with a token that stands in for it within a defined system or process.

Example: A payment workflow stores a service-provided token instead of displaying the full payment detail in an ordinary business tool.
Do not confuse with: Do not confuse tokenization with encryption or hashing: tokenization substitutes a reference, while encryption transforms recoverable data and hashing produces a comparison representation.
Why it matters: It can reduce the places where a system handles sensitive values when the token service and access controls are appropriate.
Defensive next step: Ask the service owner what the token represents, where the mapping is protected, and which actions remain in scope.
Context: Token properties and reversibility depend on the system; this entry is conceptual and not a payment-compliance conclusion.

Reviewed: 2026-09-29

Confidentiality

Also known as: data confidentiality

Confidentiality is the property that information is not disclosed to unauthorised people, processes, or systems.

Example: A shared cloud folder limits access to the team members who need the documents for their work.
Do not confuse with: Do not confuse confidentiality with integrity or availability: confidentiality concerns unauthorised disclosure, integrity concerns unwanted change, and availability concerns access when needed.
Why it matters: It helps an owner identify who should be able to view information and what exposure a control is meant to reduce.
Defensive next step: Review sharing permissions, transmission paths, and storage access with the authorised data owner.
Context: The CIA properties are used in different standards and contexts; this is a plain-language security objective.

Reviewed: 2026-09-29

Integrity

Also known as: data integrity

Integrity is the property that information or system behaviour remains accurate, complete, and protected from unauthorised or unexpected change.

Example: A small business compares an invoice record with an authorised source after noticing an unexpected edit.
Do not confuse with: Do not confuse integrity with confidentiality, availability, or authenticity: a record may be private yet changed, or unchanged yet from an untrusted source.
Why it matters: It helps people notice and investigate changes that could affect decisions, payments, or recovery.
Defensive next step: Use authorised change records, access review, and suitable integrity checks for important data.
Context: The exact integrity objective varies by system and source; a check does not by itself identify who made a change.

Reviewed: 2026-09-29

Devices, networks, and cloud

Introduce the everyday building blocks that help a device find, reach, and communicate with services.

IP address

Also known as: internet protocol address

An IP address is a network-layer address used to identify an interface or endpoint for communication within a particular addressing context.

Example: A laptop receives an address from its home network so it can request a cloud service.
Do not confuse with: Do not confuse an IP address with a person, identity, location proof, or trust decision; an address helps route traffic but does not prove who controls it.
Why it matters: Understanding addresses helps a beginner read basic service or support information without treating routing data as identity evidence.
Defensive next step: Record the address only through an authorised diagnostic or support view and avoid publishing sensitive network details unnecessarily.
Context: Address types, assignment, and privacy vary across networks; this is not an instruction to scan or probe systems.

Reviewed: 2026-09-29

DNS (DNS)

Also known as: domain name system

DNS is the naming service that helps map a domain or service name to network information used to connect.

Example: A browser uses DNS to find the destination for a learning service before establishing its protected connection.
Do not confuse with: Do not confuse DNS with a firewall, identity check, or HTTPS: name resolution helps locate a destination but does not prove that the destination or request is trustworthy.
Why it matters: It clarifies why a service may be unreachable or misdirected while keeping naming separate from access and trust decisions.
Defensive next step: Use the network or service owner’s supported DNS settings and verify unexpected destination warnings through authorised support.
Context: DNS records, resolvers, and encrypted DNS have different properties; this entry stays at the basic name-resolution level.

Reviewed: 2026-09-29

Firewall

Also known as: network firewall

A firewall is a control that applies rules to allow, block, or otherwise handle network traffic at a defined boundary.

Example: A small office reviews its router firewall rules with an authorised administrator and removes an unnecessary exception.
Do not confuse with: Do not confuse a firewall with complete cybersecurity or with an application’s authorization; traffic filtering cannot fix stolen credentials, unsafe software, or missing backups.
Why it matters: It can reduce unwanted network exposure when its rules, administration, and surrounding controls are maintained.
Defensive next step: Ask the authorised owner to review enabled status, important exceptions, support status, and the least access needed.
Context: Firewall capabilities and placement differ across devices and services; a firewall is not a guarantee.

Reviewed: 2026-09-29

TLS/HTTPS (TLS/HTTPS)

Also known as: HTTPS, TLS, transport layer security

TLS/HTTPS is an application connection pattern in which HTTP traffic uses Transport Layer Security to help protect the channel between a client and service.

Example: A browser shows HTTPS while a remote worker accesses a cloud service, so the user still checks the correct site and account before continuing.
Do not confuse with: Do not confuse HTTPS with trust: it can protect the relevant channel but does not prove that a site, sender, account, or payment request is legitimate.
Why it matters: It can reduce exposure while data crosses networks when the client, service, certificate handling, and endpoint are appropriate.
Defensive next step: Check the intended domain and browser security details, and never treat HTTPS alone as a reason to approve an unexpected request.
Context: TLS versions and deployment guidance evolve; this entry makes no current universal configuration claim.

Reviewed: 2026-09-29

VPN (VPN)

Also known as: virtual private network

A VPN is a service or technology that creates a protected connection for traffic routed through it across another network.

Example: A remote worker uses an organisation-approved VPN on home Wi-Fi for the traffic the organisation has configured it to carry.
Do not confuse with: Do not confuse a VPN with anonymity: a VPN can protect traffic routed through it, but it does not promise anonymity or replace endpoint, account, or service security.
Why it matters: It can reduce exposure on an untrusted network for the traffic and endpoints within its configured scope.
Defensive next step: Use only an approved VPN, confirm which traffic it covers, and keep the client, account, and endpoint supported.
Context: VPN protection depends on routing, endpoint, provider, and organisational configuration; NCSC guidance is not consumer anonymity advice.

Reviewed: 2026-09-29

Network segmentation

Also known as: segmentation, network zones

Network segmentation separates systems or traffic into zones so access between them can be limited by policy.

Example: A small office places visitors on guest Wi-Fi and keeps administrative equipment in a separately managed zone when its equipment supports that design.
Do not confuse with: Do not confuse segmentation with a guarantee that a zone is safe; a weak rule, shared credential, or compromised endpoint can still cross or bypass intended boundaries.
Why it matters: Limiting unnecessary paths can reduce the scope of some mistakes or harmful activity.
Defensive next step: With an authorised owner, list which devices need to reach which services and review the boundary rules rather than adding unexplained complexity.
Context: Design trade-offs and implementation belong to a deeper network guide; this is a compact conceptual entry.

Reviewed: 2026-09-29

Cloud service

Also known as: cloud computing service

A cloud service is a computing, storage, application, or platform capability provided over a network by a service operator.

Example: A small business stores a shared folder with a cloud provider and assigns access to named staff.
Do not confuse with: Do not confuse a cloud service with a fully outsourced security responsibility; provider and customer duties are shared according to the service and contract.
Why it matters: Knowing who operates each layer helps an owner set permissions, updates, logging, recovery, and escalation expectations.
Defensive next step: Read the service’s responsibility and recovery information, assign an owner, and review access and sharing settings.
Context: Allocation varies by IaaS, PaaS, SaaS, provider, feature, and contract; it is not a legal conclusion or guarantee.

Reviewed: 2026-09-29

Detection and response

Connect records, monitoring, maintenance, suspected events, restoration, and learning after a problem.

Logs

Also known as: log records, event logs

Logs are records of events or actions generated by a device, application, network, identity system, or service.

Example: An administrator reviews an account sign-in and configuration-change record after a user reports an unexpected update.
Do not confuse with: Do not confuse logs with complete visibility or proof of intent; missing coverage, inaccurate time, or retention limits can leave important gaps.
Why it matters: Useful records can help establish what changed, when, and which authorised owner should investigate next.
Defensive next step: Identify important event types, protect access and retention, and confirm that time and ownership are understandable.
Context: Retention and reporting requirements depend on system, organisation, and applicable context; CERT-In directions are scope-limited.

Reviewed: 2026-09-29

Monitoring

Also known as: security monitoring

Monitoring is the ongoing review of relevant activity, signals, or system state to identify changes that may need attention.

Example: A small business reviews unusual sign-in alerts and device inventory changes through its approved administration console.
Do not confuse with: Do not confuse monitoring with guaranteed detection or constant surveillance; an unalerted event may still occur when coverage is incomplete.
Why it matters: It gives an owner a way to notice changes and connect them to an authorised decision or response path.
Defensive next step: Choose a small set of useful signals, name a reviewer, and document what action a meaningful alert should start.
Context: Coverage, privacy, time accuracy, and escalation depend on the environment; monitoring is not a claim that all activity is observed.

Reviewed: 2026-09-29

Indicator of compromise (IoC)

Also known as: ioc, compromise indicator

An indicator of compromise is an observable sign that may suggest a system, account, or data has been affected by harmful or unauthorised activity.

Example: A support team reviews an unusual sign-in record and a sudden configuration change as possible indicators while checking other evidence.
Do not confuse with: Do not confuse an indicator with proof of compromise, attribution, or a complete incident assessment; it is a signal that needs context.
Why it matters: Treating signals as clues supports careful preservation and escalation without overclaiming what happened.
Defensive next step: Record the signal, time, source, and affected asset, then send it through the authorised support or response route.
Context: Indicator lists and confidence depend on source, environment, and investigation; do not test or search for indicators on systems without authority.

Reviewed: 2026-09-29

Patching

Also known as: software updates, security update

Patching is applying a supported software or firmware fix or update to address defects, including security weaknesses.

Example: A device owner installs a supported operating-system update and confirms the device returns to normal operation.
Do not confuse with: Do not confuse patching with complete security or secure configuration; updates reduce some known exposure but cannot fix every unsafe action, credential, or backup issue.
Why it matters: Current supported software can reduce exposure to known weaknesses and improve maintainability.
Defensive next step: Check the publisher or device owner’s supported update path, record the result, and plan replacement or isolation for unsupported equipment.
Context: Support status, update timing, and safe compatibility vary by product and environment; no specific vendor performance is claimed.

Reviewed: 2026-09-29

Backups

Also known as: backup copy, recovery copy

A backup is a separate or otherwise protected copy of data kept so it can be restored after loss, corruption, or another disruptive event.

Example: A family protects important documents in a separate recovery copy and periodically restores a non-production sample to check it works.
Do not confuse with: Do not confuse a backup with sync: a synced copy can reproduce unwanted changes, while recovery depends on protected, independent, tested copies.
Why it matters: Protected copies can support recovery when working data, an account, or a device is unavailable or altered.
Defensive next step: Identify important data, protect the backup administration, keep an independent copy where appropriate, and test a restore.
Context: Backup design, retention, encryption, and recovery objectives depend on the owner and system; a backup is not a guarantee of recovery.

Reviewed: 2026-09-29

Incident response

Also known as: IR, cyber incident response

Incident response is the organised process of preparing for, identifying, handling, communicating about, and learning from a suspected or confirmed cybersecurity incident.

Example: A small business follows its approved contacts to record an account problem, contain safely, preserve details, and restore from a suitable copy.
Do not confuse with: Do not confuse incident response with improvised investigation, retaliation, or a universal reporting duty; CERT-In institutional directions and victim or police complaint routes have different contexts.
Why it matters: A prepared response can reduce confusion and protect evidence, roles, communications, and recovery choices.
Defensive next step: Keep a short authorised plan with contacts and priorities, and use it instead of deleting records or trying unapproved technical actions.
Context: Guidance and reporting scope vary by organisation and jurisdiction; this entry is not legal, forensic, or guaranteed recovery advice.

Reviewed: 2026-09-29

Recovery

Also known as: service recovery, data recovery

Recovery is the process of restoring data, systems, services, and normal operations after a disruptive event.

Example: After an account incident, an authorised owner restores access and data from a known-good copy, verifies the service, and records remaining limits.
Do not confuse with: Do not confuse recovery with backup alone or with a guarantee of a particular time or outcome; recovery also needs decisions, checks, dependencies, and communication.
Why it matters: It makes resilience a practical activity rather than assuming that a stored copy automatically returns everything to normal.
Defensive next step: Define recovery priorities, test an agreed restoration path, verify the result, and update contacts and dependencies.
Context: Recovery objectives and results vary by system, copy, authority, and incident; no recovery-time or outcome claim is made.

Reviewed: 2026-09-29

Governance, software, and careers

Place frameworks, controls, shared provider/customer duties, software dependencies, secure development, and workforce language in context.

NIST CSF Functions (CSF)

Also known as: NIST Cybersecurity Framework Functions, CSF Functions

NIST CSF Functions are the high-level Govern, Identify, Protect, Detect, Respond, and Recover outcomes used to organise cybersecurity risk work.

Example: A small organisation uses the Functions as prompts to discuss assets, access, monitoring, response, and restoration without turning them into a fixed checklist.
Do not confuse with: Do not confuse CSF Functions with Indian law, a certification, a job title, a ranking, or a security guarantee; they are non-prescriptive risk guidance.
Why it matters: They provide shared structure for discussing different parts of cybersecurity and finding gaps in an organisation’s approach.
Defensive next step: Use the Functions as a discussion map, record the organisation’s scope, and choose practical next actions with an accountable owner.
Context: NIST describes the CSF as flexible and non-prescriptive for organisations; it is not a universal compliance determination.

Reviewed: 2026-09-29

Zero trust

Also known as: zero trust architecture, ZTA

Zero trust is an approach that avoids granting implicit trust based only on network location or ownership and instead uses appropriate identity, device, and context decisions for access.

Example: A cloud service checks the account, device condition, and requested resource before allowing a particular action, rather than trusting every request from an office network.
Do not confuse with: Do not confuse zero trust with a product, total distrust of people, or a guarantee; it is an architecture and risk approach with implementation limits.
Why it matters: It encourages explicit, least-privilege decisions at resources and boundaries that may be distributed across cloud and local systems.
Defensive next step: Ask which identity, device, resource, and context decisions an authorised system actually makes before adopting the label.
Context: NIST guidance is enterprise-oriented and evolving; this is not a household prescription or product endorsement.

Reviewed: 2026-09-29

Security control

Also known as: control, safeguard, countermeasure

A security control is a safeguard or countermeasure intended to protect information or systems and address a stated security requirement or risk.

Example: A business uses MFA, access review, and protected backups as different controls for different account and recovery concerns.
Do not confuse with: Do not confuse a control with a guarantee, product, or complete programme; a control has a purpose, scope, owner, and limitation.
Why it matters: Naming the control and its intended risk helps an owner check whether it is present, maintained, and appropriate.
Defensive next step: Document the control’s purpose, owner, evidence, review date, and remaining limitation.
Context: Definitions and control catalogues vary by framework and organisation; this is a context-bounded NIST-style description.

Reviewed: 2026-09-29

Shared responsibility

Also known as: cloud shared responsibility

Shared responsibility is the allocation of security-related duties between a cloud provider and its customer for a particular service and configuration.

Example: A cloud provider maintains part of the platform while the business manages account permissions, data sharing, and its own devices.
Do not confuse with: Do not confuse shared responsibility with transferred responsibility, a contract summary, or a guarantee; the allocation changes by service model, feature, and provider.
Why it matters: It prevents an owner from assuming that a provider manages customer settings or that the customer controls provider infrastructure.
Defensive next step: Read the current service responsibility information, assign owners for customer-controlled settings, and review changes.
Context: Provider documents and contracts govern the actual allocation; UK NCSC and Microsoft explanations are illustrative, not Indian law.

Reviewed: 2026-09-29

Software supply chain

Also known as: software supply-chain security, dependency chain

A software supply chain is the people, processes, code, dependencies, tools, and distribution paths involved in producing and delivering software.

Example: A small business asks its software provider how updates and important dependencies are managed before enabling a new service.
Do not confuse with: Do not confuse software supply-chain security with a single scanner, a software bill of materials alone, or a guarantee that software is safe.
Why it matters: Understanding dependencies and provenance can help an owner ask who changes software and how updates are reviewed.
Defensive next step: Keep an inventory of important software and providers, use supported update channels, and review unexpected change through an authorised owner.
Context: The term covers producer and consumer practices; the OWASP source focuses on current software-supply-chain failure categories and mitigations.

Reviewed: 2026-09-29

Secure SDLC/DevSecOps (SDLC/DevSecOps)

Also known as: secure software development lifecycle, DevSecOps, secure SDLC

Secure SDLC/DevSecOps integrates security considerations into software planning, design, implementation, verification, release, and operation.

Example: A development team reviews access, data handling, dependencies, and tests during a feature’s lifecycle instead of waiting until release.
Do not confuse with: Do not confuse secure SDLC/DevSecOps with a certification, a tool, or a guarantee that software has no defects; it is a lifecycle and practice approach.
Why it matters: Earlier and repeated review can help teams identify security requirements and manage changes with clearer ownership.
Defensive next step: Ask the authorised team where security requirements, code review, dependency review, testing, release approval, and operational feedback fit in the lifecycle.
Context: Practices vary by team, product, and risk; this entry remains at a process level and gives no exploit or testing instructions.

Reviewed: 2026-09-29

NICE work and roles (NICE)

Also known as: NICE Framework, NICE work roles

NICE work and roles are shared workforce language describing cybersecurity work, tasks, knowledge, and skills.

Example: A learner uses a NICE work-role description to compare interests with study or workplace tasks without treating it as a job offer or required title.
Do not confuse with: Do not confuse NICE with Indian law, a certification, a fixed job title, salary information, or a security guarantee; it is shared workforce language.
Why it matters: Common language can help learners, educators, and employers describe work without assuming every organisation uses identical titles.
Defensive next step: Read the current role and task descriptions, then compare them with the actual organisation, learning path, and job requirements.
Context: NIST says the framework is adaptable reference language; it does not determine hiring, pay, certification, or legal status.

Reviewed: 2026-09-29

Foundations and risk

Cybersecurity

Asset

Threat (None)

Vulnerability

Risk

Incident

Cybercrime

Identity and access

Identity

Authentication (AuthN)

Authorization (AuthZ)

Multi-factor authentication (MFA)

Identity proofing

Session

Least privilege

Scams and harmful code

Phishing

Smishing

Vishing

Social engineering

Malware

Virus

Ransomware

Data and cryptography

Encryption

Hashing

Hash value

Tokenization

Confidentiality

Integrity

Devices, networks, and cloud

IP address

DNS (DNS)

Firewall

TLS/HTTPS (TLS/HTTPS)

VPN (VPN)

Network segmentation

Cloud service

Detection and response

Logs

Monitoring

Indicator of compromise (IoC)

Patching

Backups

Incident response

Recovery

Governance, software, and careers

NIST CSF Functions (CSF)

Zero trust

Security control

Shared responsibility

Software supply chain

Secure SDLC/DevSecOps (SDLC/DevSecOps)

NICE work and roles (NICE)