Corporate Cybersecurity Assessment Questionnaire

What NIST requires

NIST requires that the organizational mission be clearly documented and that it guide cybersecurity decisions. Asset protection decisions must be consistent with the organization's strategic objectives, ensuring that security investments are aligned with actual business priorities.

Practical examples

Corporate mission statement that includes references to cybersecurity, strategic plan with security objectives, board presentation linking mission and cyber risk.

What NIST requires

The organization must identify all internal stakeholders (employees, management, board of directors) and external stakeholders (customers, partners, regulatory authorities) and understand their cybersecurity expectations. This enables the security strategy to be calibrated to the concrete needs of those who depend on the organization.

Practical examples

Stakeholder register with their respective security expectations, minutes from meetings with clients/partners on cybersecurity, analysis of security requirements demanded by key customers.

What NIST requires

The framework requires full understanding and management of all legal, regulatory, and contractual obligations related to cybersecurity, including GDPR, NIS2, DORA, and sector-specific requirements. Non-compliance can result in significant penalties, civil and criminal liability, as well as reputational damage.

Practical examples

Register of applicable regulations (GDPR, NIS2, DORA, industry-specific regulations), up-to-date compliance checklist, periodic legal counsel on cyber obligations, regulatory monitoring procedure.

What NIST requires

The organization must know which of its services and capabilities are critical to external parties (customers, partners, supply chain). This enables establishing protection priorities and transparently communicating the level of reliability and security guaranteed.

Practical examples

List of critical services provided to third parties with associated security SLAs, communications to customers on security posture, security certifications shared with customers (e.g., ISO 27001).

What NIST requires

NIST requires mapping the organization's external dependencies: cloud services, ICT suppliers, critical infrastructure, connectivity. Understanding who the organization depends on is essential for assessing disruption risks and defining adequate business continuity plans.

Practical examples

Map of external dependencies (cloud providers, ISPs, critical suppliers), impact analysis in the event each external service becomes unavailable, contingency plans for key dependencies.

What NIST requires

Risk management objectives must be formally defined and agreed upon with key stakeholders (management, board of directors, function heads). This ensures a shared and consistent approach to security, preventing fragmented or conflicting decisions.

Practical examples

Risk management strategy document approved by the board, minutes of objective-setting meetings, formal risk appetite statement.

What NIST requires

Risk appetite (how much risk the organization is willing to accept) and risk tolerance (specific thresholds by risk type) must be formalized in written statements, communicated across the organization, and reviewed periodically. Without these parameters, security decisions remain subjective.

Practical examples

Written risk appetite and risk tolerance declaration by risk type (e.g., "maximum acceptable residual risk: medium"), communication to all function managers.

What NIST requires

Cyber risk management must not be an isolated process but integrated into enterprise risk management (ERM). The board and management must view cyber risk alongside financial, operational, and reputational risks in order to make informed decisions on resource allocation.

Practical examples

Risk register that includes cyber risks alongside financial and operational risks, integrated reporting to the board, ERM framework that explicitly encompasses cybersecurity.

What NIST requires

NIST requires that the organization define and communicate a clear strategic direction on risk response options: mitigate, accept, transfer (insurance), or avoid. This decision-making framework enables rapid and consistent responses when new risks emerge.

Practical examples

Decision matrix for risk response (mitigate/accept/transfer/avoid), guidelines for function managers, escalation criteria to management.

What NIST requires

Structured communication channels for cyber risks must exist at all levels of the organization, including those originating from the supply chain. Risk information must flow from the operational level to management and vice versa, without barriers or delays.

Practical examples

Defined communication channels (e.g., monthly CISO report to the board, internal alerts, security newsletter), procedures for reporting supply chain risks, periodic cross-functional meetings.

What NIST requires

The framework requires a standardized and repeatable method to calculate, document, and prioritize cybersecurity risks. Without a uniform methodology, risk assessment becomes subjective and not comparable over time, making it impossible to measure progress.

Practical examples

Documented risk assessment methodology (e.g., based on ISO 27005 or FAIR), standardized assessment templates, uniform risk classification scale, centralized management tool.

What NIST requires

Strategic opportunities (positive risks) arising from cybersecurity must be identified and considered. A strong security posture can become a competitive advantage, a market differentiator, and an enabler for new digital initiatives.

Practical examples

Analysis of business opportunities arising from security (e.g., certifications as a competitive advantage), business case for cybersecurity investments, case studies of clients acquired thanks to security posture.

What NIST requires

Organizational leadership must assume accountability for cyber risk and actively promote a culture of security. This means the CEO, board of directors, and senior management do not delegate cybersecurity to IT alone but treat it as a strategic priority, leading by example with security-conscious behavior.

Practical examples

Formal appointment of a CISO or cybersecurity officer, board agenda that regularly includes cybersecurity, code of ethics referencing information security, security culture program.

What NIST requires

Every role related to cyber risk management must be formally defined, documented, and communicated. Individuals must know exactly what is expected of them in terms of security, and decision-making authorities must be clear to avoid accountability gaps.

Practical examples

Organizational chart with cybersecurity roles, job descriptions that include security responsibilities, RACI matrix for security processes, formal communication of roles to all personnel.

What NIST requires

Resources (budget, personnel, tools, training) must be adequate for the risk strategy and defined roles. A security policy without resources to implement it is ineffective. NIST requires alignment between security ambitions and concrete investments.

Practical examples

Approved dedicated cybersecurity budget, hiring/training plan for the security team, inventory of security tools and services, resource gap analysis vs. needs.

What NIST requires

Cybersecurity must be integrated into HR processes: from personnel selection (background checks), to initial training, to access management during employment, through to secure access revocation upon termination. The human factor is the primary risk vector.

Practical examples

HR policy that includes pre-employment screening, mandatory security training at onboarding, access revocation procedure upon termination, confidentiality clauses in employment contracts.

What NIST requires

The organization must have a formal cybersecurity policy based on its operational context and risk strategy. The policy must be communicated at all levels and enforced consistently. Without a clear policy, security decisions become arbitrary and inconsistent.

Practical examples

Cybersecurity policy approved by management and published on the intranet, acceptable use policy for IT resources, password management policy, data classification policy.

What NIST requires

The cybersecurity policy is not a static document: it must be reviewed and updated regularly to reflect changes in the threat landscape, technology, regulatory requirements, and business mission. NIST recommends reviews at least annually or following significant incidents.

Practical examples

Policy revision log with dates and rationale, annual update procedure, triggers for extraordinary revision (e.g., after an incident or regulatory change), communication of updates.

What NIST requires

The outcomes of the cyber risk management strategy must be regularly reviewed to verify whether the direction taken is effective. Metrics, KPIs, and periodic reports enable management to make decisions based on concrete data rather than perceptions.

Practical examples

Security KPI dashboard (e.g., mean patching time, number of incidents, compliance percentage), quarterly report to the board, minutes of strategic reviews with corrective actions.

What NIST requires

The risk strategy must be periodically reassessed to ensure it adequately covers all requirements and risks of the organization, including emerging ones. Changes in business, technology, or the threat landscape can render a previously effective strategy obsolete.

Practical examples

Annual review of the risk strategy, gap analysis against new threats or regulations, update of the security strategic plan based on previous year's results.

What NIST requires

The overall performance of cyber risk management must be evaluated systematically. This includes the effectiveness of controls, the timeliness of incident response, compliance with policies, and the achievement of defined security objectives.

Practical examples

Internal/external cybersecurity audit, performance metrics (e.g., incident response time, vulnerability coverage), industry benchmarking, improvement plan based on results.

What NIST requires

NIST requires a structured Cyber Supply Chain Risk Management (C-SCRM) program with strategy, objectives, and processes shared with stakeholders. Supply chain attacks are growing rapidly and can compromise even well-protected organizations through their suppliers.

Practical examples

Documented C-SCRM program with objectives and KPIs, supply chain security policy approved by management, dedicated budget for supplier risk management.

What NIST requires

Cybersecurity roles for suppliers, customers, and partners must be clearly defined and coordinated. Every actor in the chain must know what they are responsible for in terms of security, both contractually and operationally.

Practical examples

Contractual clauses defining security responsibilities for each supplier, supplier-organization RACI matrix, periodic security coordination meetings with key partners.

What NIST requires

Supply chain risk management must not be a separate process but integrated into enterprise risk management processes. Risks originating from suppliers must be assessed and managed using the same methodology applied to internal risks.

Practical examples

Supply chain risks included in the corporate risk register, supplier assessments integrated into the risk assessment process, unified internal + supply chain risk reporting.

What NIST requires

Suppliers must be inventoried and classified based on the criticality of the service provided and the level of access to the organization's systems and data. A supplier with privileged access to critical systems requires a much higher level of scrutiny than one providing marginal services.

Practical examples

Supplier register with criticality classification (high/medium/low), documented classification criteria, periodic classification review.

What NIST requires

Cybersecurity requirements must be explicitly included in contracts with suppliers and third parties. Clauses on minimum security standards, breach notification obligations, audit rights, and incident response SLAs are essential for effective risk management.

Practical examples

Contract template with standard security clauses, minimum security requirements for suppliers (e.g., ISO 27001, SOC 2), pre-contract verification checklist.

What NIST requires

Before establishing formal relationships with new suppliers, NIST requires due diligence activities to assess their security posture. This includes verifying certifications, analyzing security practices, and evaluating the organizational strength of the supplier.

Practical examples

Pre-contract due diligence procedure, security questionnaire for new suppliers, certification verification, analysis of the supplier's financial stability.

What NIST requires

Monitoring risks posed by suppliers does not end with initial due diligence but must continue throughout the relationship. Risks must be periodically reassessed, especially in light of significant changes in the supplier or the threat landscape.

Practical examples

Continuous supplier monitoring (e.g., security rating), periodic audits of critical suppliers, risk reassessment following incidents or significant supplier changes.

What NIST requires

Critical suppliers must be involved in incident response and recovery plans. In the event of an incident, timely collaboration with suppliers is often decisive for containment and recovery. Joint exercises verify that procedures work effectively.

Practical examples

Incident response plan that includes supplier roles, joint exercises (tabletop exercises), emergency communication procedures with critical suppliers.

What NIST requires

Supply chain security practices must be monitored throughout the entire lifecycle of purchased products and services, from acquisition to decommissioning. NIST requires that this monitoring be integrated into existing risk management programs.

Practical examples

Monitoring of patches and vulnerabilities in supplier products, security verification throughout the lifecycle (acquisition, use, decommissioning), supply chain security KPIs.

What NIST requires

Risk management plans must address what happens when a partnership or service agreement ends. Secure return or destruction of data, access revocation, and transfer of responsibilities must be planned in advance.

Practical examples

Contractual exit management clauses, data return/destruction procedure at contract end, supplier offboarding checklist, verification of access revocation.

What NIST requires

NIST requires an accurate and up-to-date inventory of all hardware devices managed by the organization: servers, PCs, mobile devices, network equipment, IoT. You cannot protect what you do not know about. The inventory must include the owner, location, status, and criticality of each asset.

Practical examples

CMDB or up-to-date hardware inventory, periodic network scans to identify unregistered devices, asset tagging, registration process for new devices.

What NIST requires

Similarly to hardware, all software in use must be cataloged, including cloud platforms and SaaS services. A software inventory enables identifying outdated versions, non-compliant licenses, and unauthorized applications (shadow IT), which is fundamental for vulnerability management.

Practical examples

Software inventory with versions and licenses, scans to detect shadow IT, register of subscribed SaaS and cloud services, approval process for new software.

What NIST requires

The framework requires mapping communication and data flows within and outside the organization. Understanding how data moves between systems, networks, and partners is essential for identifying exposure points, segmenting the network, and applying adequate access controls.

Practical examples

Up-to-date network diagrams, data flow mapping (data flow diagrams), documentation of external connections (VPNs, APIs, partner interconnections).

What NIST requires

Every service provided by third parties that impacts security must be inventoried. Every external supplier represents a potential attack vector: knowing who provides what and with what level of access is a prerequisite for managing supply chain risk.

Practical examples

Register of IT/cloud service providers detailing services delivered, level of data access, agreed SLAs, active contracts.

What NIST requires

Not all assets have the same importance. NIST requires that they be classified based on criticality to the business mission. This enables allocating security resources proportionally: systems that handle sensitive data deserve more stringent protections.

Practical examples

Asset classification matrix (critical/important/standard), impact assessment in case of compromise, defined protection and recovery priorities.

What NIST requires

Data is often the most valuable asset. NIST requires an inventory that describes what data is processed, where it is stored, who owns it, and what sensitivity level it has. This is essential for data protection and GDPR compliance.

Practical examples

Data processing register (required by GDPR), data classification (public, internal, confidential, secret), mapping of data repositories, identification of data owners.

What NIST requires

Every asset must be securely managed from acquisition to decommissioning. This means having documented processes for secure initial configuration, regular patch application, maintenance, and secure disposal with data erasure.

Practical examples

Lifecycle management procedure for hardware and software, hardening process for new systems, patching plan, secure decommissioning procedure (e.g., NIST SP 800-88 for sanitization).

What NIST requires

NIST requires a systematic process for identifying vulnerabilities. It is not enough to know they exist: they must be validated, classified by severity (for example using the CVSS system), and recorded so that the most critical ones can be addressed first.

Practical examples

Periodic vulnerability scans (at least quarterly), annual penetration tests, tracking of relevant CVEs, vulnerability prioritization and remediation process.

What NIST requires

Threat intelligence enables anticipating threats. The organization must leverage information sources: national CERT bulletins, vendor advisories, indicators of compromise feeds, and information shared with industry organizations (ISACs).

Practical examples

Subscription to CERT bulletins (e.g., CISA alerts, US-CERT), threat intelligence feed subscriptions, participation in industry ISACs, monitoring of vendor advisories.

What NIST requires

NIST requires a comprehensive catalog of threats, both external (cybercriminals, hacktivists, state actors) and internal (malicious insiders, human errors). Each threat must be documented with motivation, capability, and potentially targeted assets.

Practical examples

Threat register with profiles of attackers relevant to the industry, insider threat analysis, periodic threat landscape assessment.

What NIST requires

For each threat-vulnerability pair, the organization must estimate the likelihood of exploitation and the impact in case of success (financial, operational, reputational, legal). This analysis, typically in a risk matrix, enables informed decisions on resource allocation.

Practical examples

Likelihood/impact matrix for risk scenarios, assessment of financial/operational/reputational impact, documented attack scenarios with probability estimates.

What NIST requires

After analyzing threats and vulnerabilities, NIST requires determining residual risk and using this information to prioritize actions. The organization must define its risk appetite and focus resources on risks that exceed this threshold.

Practical examples

Risk register with residual risk calculated for each scenario, comparison against defined risk appetite, prioritized treatment plan, risk scoring dashboard.

What NIST requires

For each identified risk, a documented decision is required: mitigate, accept, transfer (e.g., cyber insurance), or avoid. Each decision must be tracked in a risk treatment plan with responsible parties, deadlines, and stakeholder communication.

Practical examples

Risk treatment plan with actions, owners and deadlines, formal risk acceptance signed by management, cyber insurance policies, status reporting on actions.

What NIST requires

Changes to IT infrastructure and policy exceptions are moments of elevated risk. NIST requires a change management process that assesses the security impact before implementing modifications. Exceptions must be approved, documented, and time-bound.

Practical examples

Change management process with security assessment, register of policy exceptions with approval and expiration, periodic review of active exceptions.

What NIST requires

The organization must have a structured process for receiving, analyzing, and responding to vulnerability reports from both internal and external sources (security researchers, vendors). This includes a responsible disclosure procedure.

Practical examples

Dedicated email address or portal for vulnerability reporting, published responsible disclosure procedure, internal process for analyzing and responding to reports.

What NIST requires

Before acquiring and deploying hardware and software, NIST requires verification of their authenticity and integrity. Counterfeit or tampered products may contain backdoors or malware that compromise the security of the entire infrastructure.

Practical examples

Verification of hardware/software supplier authenticity, software digital signature checks, procurement only through authorized channels, firmware integrity verification.

What NIST requires

Critical suppliers must be assessed in terms of risk before acquisition. Pre-contractual due diligence must include verification of security posture, certifications, financial stability, and incident response capability.

Practical examples

Pre-acquisition security questionnaire, supplier certification verification, security rating analysis, documented due diligence before contract signing.

What NIST requires

NIST requires that assessment results (audits, assessments, reviews) be systematically analyzed to identify areas for improvement. Each assessment must produce concrete and trackable recommendations, with responsible parties and deadlines for implementation.

Practical examples

Audit report with recommendations and action plan, tracking of recommendation implementation, review of improvements implemented.

What NIST requires

Security tests and exercises (penetration tests, red teaming, tabletop exercises) must be used to identify improvements. Involving suppliers in these activities is important for verifying the resilience of the entire value chain.

Practical examples

Penetration test results with corrective actions, lessons learned from security exercises, improvements implemented after joint tests with suppliers.

What NIST requires

Day-to-day operations are a valuable source of improvements. Recurring problems, near-misses, and inefficiencies in security processes must be systematically captured and analyzed to feed a continuous improvement cycle.

Practical examples

Log of lessons learned from daily operations, near-miss analysis, improvement proposals from the operations team, periodic review of security processes.

What NIST requires

Incident response plans and other cybersecurity plans must be living documents: defined, communicated to those who need to use them, periodically tested, and improved based on lessons learned. An untested plan is little more than a statement of intent.

Practical examples

Tested and updated incident response plan, disaster recovery plan, business continuity plan, log of reviews and tests performed with results.

What NIST requires

All digital identities (users, services, devices) must be centrally managed with documented creation, modification, and deactivation processes. The organization must have complete control over who and what has access to its systems.

Practical examples

Centralized identity management system (Active Directory, Entra ID, etc.), account provisioning/deprovisioning process, periodic review of active accounts.

What NIST requires

Identities must be verified and associated with credentials in a manner proportionate to the context: access to critical data from an external network requires more stringent verification than access to non-sensitive resources from the internal network.

Practical examples

Context-based adaptive authentication (location, device, time), differentiated verification levels for high/low criticality access, identity verification for credential resets.

What NIST requires

NIST requires that all users, services, and hardware be authenticated before accessing resources. Multi-factor authentication (MFA) is strongly recommended, particularly for privileged and remote access.

Practical examples

Multi-factor authentication (MFA) enabled for all critical and remote access, password policy (complexity, rotation), certificates for service and device authentication.

What NIST requires

Identity assertions (tokens, certificates, federated credentials) must be protected during transmission and verified at the time of use. The compromise of an identity mechanism can allow unauthorized access to all connected systems.

Practical examples

Session tokens protected with encryption, digital certificates for identity federation, token verification upon resource access, secure protocols (OAuth 2.0, SAML).

What NIST requires

Access permissions must follow the principle of least privilege (each user has only the access strictly necessary) and separation of duties (no single individual has complete control over a critical process). Permissions must be reviewed periodically.

Practical examples

Access permission matrix by role, quarterly access reviews, enforcement of the principle of least privilege, separation of duties for critical processes.

What NIST requires

Physical access to data centers, server rooms, network cabinets, and other critical assets must be controlled, monitored, and logged. Physical security measures must be proportionate to the risk and value of the protected assets.

Practical examples

Access badges for restricted areas, physical access logs, data center video surveillance, visitor escort procedures, electronic locks for network cabinets.

What NIST requires

All personnel must receive cybersecurity training appropriate to their role. This includes phishing awareness, secure password management, recognition of suspicious behavior, and procedures to follow in the event of an incident.

Practical examples

Mandatory annual cybersecurity training for all employees, periodic phishing simulations, informational materials on the intranet, awareness campaigns.

What NIST requires

Individuals with specialized roles (IT administrators, developers, security analysts) must receive specific and up-to-date technical training on threats and security practices relevant to their duties.

Practical examples

Technical courses for IT administrators (e.g., system security, hardening), developer training on secure coding (OWASP), security certifications for key roles.

What NIST requires

Stored data (on disks, databases, backups, removable media) must be protected with encryption, access controls, and integrity mechanisms. Data-at-rest protection is fundamental for preventing loss of confidentiality in the event of physical theft or unauthorized access.

Practical examples

Disk encryption (BitLocker, FileVault), database encryption for sensitive data, file and repository access controls, data loss prevention (DLP) policies.

What NIST requires

Data in transit (over internal networks, the internet, VPNs) must be protected with cryptographic protocols (TLS, IPsec). NIST requires that sensitive communications cannot be intercepted or modified during transmission.

Practical examples

TLS/HTTPS for all web communications, VPN for remote connections, encryption of sensitive emails, IPsec for site-to-site connections.

What NIST requires

Data in use (in RAM, cache, during processing) must also be protected. Techniques such as in-memory encryption and process access controls contribute to protecting data during active processing.

Practical examples

Application memory protection, controls on running process access, secure processing environments for sensitive data (e.g., secure enclaves, confidential computing).

What NIST requires

Backups must be created regularly, protected (encrypted and with restricted access), stored securely (including off-site), and periodically tested to verify recoverability. An untested backup is not a reliable backup.

Practical examples

Automated daily backups with encryption, off-site or separate cloud copies, periodic restore tests (at least semi-annually), backup retention policy, immutable backups.

What NIST requires

NIST requires configuration management practices: security baselines for all systems, hardening processes, centralized configuration management, and deviation monitoring. Misconfigurations are among the most common causes of vulnerabilities.

Practical examples

Secure configuration baseline for servers and workstations (CIS Benchmarks), centralized configuration management, monitoring of baseline deviations, hardening process.

What NIST requires

Software must be kept up to date with security patches, replaced when it reaches end-of-life, and removed when no longer needed. Obsolete software no longer receives updates and becomes an easy target.

Practical examples

Patch management process with SLAs (e.g., critical patches within 72 hours), software inventory with end-of-support dates, replacement plan for obsolete software.

What NIST requires

Hardware must be maintained, replaced when obsolete, and decommissioned securely (with data erasure). NIST requires that the hardware lifecycle be managed in proportion to the risk.

Practical examples

Hardware maintenance plan, device health monitoring, replacement procedure for obsolete hardware, secure decommissioning with certified data erasure.

What NIST requires

Security logs must be generated by all critical systems and made available for continuous monitoring and forensic investigations. Logs must be protected from tampering and retained for a period adequate to regulatory and operational requirements.

Practical examples

Centralized logging via SIEM, logging policy for all critical systems, log retention for at least 12 months, log tamper protection.

What NIST requires

The organization must implement controls to prevent the installation and execution of unauthorized software: application whitelisting, group policy settings, installation rights controls. Unauthorized software is a common malware vector.

Practical examples

Application whitelisting on critical systems, group policy for blocking unauthorized installations, monitoring of running applications, script control.

What NIST requires

Software development must integrate security practices (secure SDLC): code review, security testing, dependency analysis, vulnerability management. Security must be considered from the design phase, not added as an afterthought.

Practical examples

Documented secure SDLC process, code review with security focus, SAST/DAST scans in CI/CD, dependency management and vulnerability tracking in third-party libraries.

What NIST requires

Networks must be protected from unauthorized access through firewalls, segmentation, intrusion detection systems, and network access controls. NIST requires that the network architecture be designed to limit lateral movement in the event of a compromise.

Practical examples

Perimeter and internal firewalls, network segmentation (VLANs, microsegmentation), IDS/IPS, NAC (Network Access Control), DMZ for exposed services.

What NIST requires

Technology assets must be protected from environmental threats: fires, flooding, power outages, extreme temperatures. Data centers and server rooms must have environmental protection systems (UPS, climate control, detectors, fire suppression systems).

Practical examples

UPS and generators for data centers, redundant climate control, smoke and flood detectors, fire suppression systems, surge protection.

What NIST requires

Infrastructure must be designed to ensure resilience under both normal and adverse conditions. Redundancy, automatic failover, geographic distribution, and high-availability architectures contribute to maintaining operations even during an incident.

Practical examples

High availability architecture (clustering, load balancing), automatic failover, geographic distribution of critical systems, periodic testing of resilience mechanisms.

What NIST requires

The organization must maintain sufficient resource capacity (bandwidth, compute, storage) to ensure service availability even under heavy load or during an attack. Capacity planning must account for stress scenarios and anomalous peaks.

Practical examples

Documented capacity planning, resource utilization monitoring, autoscaling for cloud services, periodic load testing.

What NIST requires

Networks must be monitored in real time to detect anomalous activity, intrusion attempts, and suspicious communications. Tools such as IDS/IPS, SIEM, and NDR enable timely identification of potential security incidents.

Practical examples

SIEM with active correlation rules, IDS/IPS in continuous monitoring, NDR (Network Detection and Response), DNS traffic monitoring, alerts on suspicious connections.

What NIST requires

The physical environment (data centers, server rooms, restricted areas) must be monitored with video surveillance systems, access sensors, and alarms to detect physical intrusions or adverse environmental events.

Practical examples

24/7 data center video surveillance, temperature/humidity sensors, intrusion alarms, real-time physical access monitoring.

What NIST requires

User activities and technology usage must be monitored to identify anomalous behavior: unusual access patterns, massive data transfers, use of unauthorized tools. User and Entity Behavior Analytics (UEBA) is an effective tool in this area.

Practical examples

UEBA (User and Entity Behavior Analytics), privileged access monitoring (PAM), alerts on anomalous activity (off-hours access, mass downloads, access from unusual locations).

What NIST requires

The activities and services of external suppliers with access to the organization's systems must be monitored. Anomalous access, unplanned changes, and suspicious behavior from suppliers may indicate a supply chain compromise.

Practical examples

Monitoring of supplier VPN/remote access, logging of supplier activities on systems, alerts on anomalous operations from supplier accounts, periodic log review.

What NIST requires

Hardware, software, runtime environments, and data must be monitored for unauthorized changes, malware, performance anomalies, and indicators of compromise. Integrity monitoring and endpoint detection are key tools.

Practical examples

EDR (Endpoint Detection and Response) on all endpoints, file integrity monitoring on critical systems, configuration change monitoring, anti-malware scans.

What NIST requires

Potentially adverse events must be analyzed in depth to understand their nature, origin, and associated activities. The analysis must go beyond the individual alert to reconstruct the chain of events and identify any ongoing attacks.

Practical examples

SOC analysts investigating alerts, analysis playbooks by event type, forensic analysis tools, preliminary investigation documentation.

What NIST requires

Information from multiple sources (logs, alerts, threat intelligence, reports) must be correlated to obtain a comprehensive view of events. Correlation is fundamental for distinguishing false positives from actual threats.

Practical examples

Automated SIEM correlation of logs from firewalls, endpoints, authentication and applications, integration of external sources (threat feeds), correlation dashboard.

What NIST requires

The potential impact and scope of an adverse event must be assessed rapidly to determine the severity and urgency of the response. This assessment guides decisions on escalation and allocation of response resources.

Practical examples

Predefined impact matrix by event type, rapid scope assessment procedure, criteria for determining the number of affected systems/data.

What NIST requires

Information about adverse events must be distributed promptly to authorized personnel and automated tools. Delays in communication can allow an attacker to expand their presence in the network.

Practical examples

Defined internal notification procedures (whom to notify and how), ticketing tools for alerts, automated alert distribution to relevant teams, emergency communication channels.

What NIST requires

Threat intelligence information (indicators of compromise, attacker TTPs, exploited vulnerabilities) must be integrated into event analysis to improve detection capabilities and understanding of the threat context.

Practical examples

IoC (Indicators of Compromise) feeds integrated into SIEM, correlation with known attacker TTPs (Tactics, Techniques and Procedures), alert enrichment with threat intelligence context.

What NIST requires

The organization must have clear and documented criteria for declaring a security incident. Not all adverse events are incidents: predefined criteria prevent both underestimation and excessive escalation, ensuring proportionate responses.

Practical examples

Documented criteria for incident declaration (e.g., severity thresholds, event types), classification matrix, escalation procedure from event to incident.

What NIST requires

When an incident is declared, the response plan must be executed in a coordinated manner, involving relevant third parties (suppliers, CERTs, authorities). Coordination is essential for effective containment and to avoid counterproductive actions.

Practical examples

Tested incident response plan accessible to the team, contact list of third parties to involve (CERT, legal, critical suppliers, insurance), plan activation checklist.

What NIST requires

Incident reports must be classified (type, severity, impact) and validated (confirmed as an actual incident) to ensure an appropriate and proportionate response. Effective triage avoids wasting resources.

Practical examples

Documented triage process with classification criteria (type, severity, impact), ticketing tools for tracking, SLAs for initial incident validation.

What NIST requires

Confirmed incidents must be categorized by type (malware, phishing, data breach, DDoS, etc.) and prioritized based on business impact, criticality of affected assets, and scope of the compromise.

Practical examples

Incident taxonomy (malware, phishing, data breach, DDoS, insider), priority matrix based on impact and urgency, criteria for automated classification.

What NIST requires

Clear escalation procedures must exist for incidents that exceed the initial response team's capabilities, involve critical assets, have legal or regulatory implications, or require management decisions.

Practical examples

Escalation procedure with defined thresholds (e.g., incidents involving personal data → DPO, incidents with financial impact → CFO), escalation matrix, 24/7 emergency contacts.

What NIST requires

NIST requires predefined criteria for determining when it is safe to begin recovery activities. Restoring too early, before the attacker has been contained, can compromise the entire recovery process.

Practical examples

Pre-recovery checklist (containment confirmation, eradication verification, management approval), objective criteria for recovery go-ahead.

What NIST requires

For each incident, a thorough analysis must be conducted to establish what happened, how the attack occurred, which assets were affected, and what the root cause was. This analysis is fundamental for preventing similar incidents in the future.

Practical examples

Root cause analysis procedure, forensic analysis tools (forensic imaging, log analysis), incident report template, event timeline.

What NIST requires

All actions performed during an investigation must be documented in detail, preserving the integrity and provenance of records. Documentation is essential both for organizational learning and for potential legal proceedings.

Practical examples

Log of investigative actions with timestamps and operator, chain of custody for evidence, tools ensuring log immutability, documented forensic procedures.

What NIST requires

Data and metadata related to the incident (logs, forensic images, malware artifacts, timelines) must be collected and preserved according to procedures that guarantee their integrity and chain of custody, including for potential legal action.

Practical examples

Forensic acquisition procedures (disk images, memory dumps, traffic capture), secure evidence storage, acquisition integrity hashes, chain of custody log.

What NIST requires

The scope of the incident (how many systems were affected, what data was compromised, what impact on the business) must be estimated as soon as possible and then validated as the investigation progresses. This estimate guides operational and communication decisions.

Practical examples

Rapid assessment of the extent of compromise (affected systems, exposed data, impacted users), progressive update of estimates as the investigation progresses.

What NIST requires

Internal stakeholders (management, board of directors, employees) and external stakeholders (customers, authorities, media) must be notified of incidents according to predefined procedures. GDPR and NIS2 impose specific notification obligations with precise timelines.

Practical examples

Data protection authority notification procedure (within 72 hours for GDPR data breaches), communication template for affected individuals, sector authority notification procedure (e.g., for NIS2 compliance).

What NIST requires

Incident information must be shared in a controlled manner with designated parties: response team, management, competent authorities, partners. Sharing must balance transparency and confidentiality to avoid compromising investigations.

Practical examples

Incident information distribution list by role, secure communication procedures (encrypted channels), update templates for management and partners.

What NIST requires

The incident must be contained as quickly as possible to prevent its spread. Containment may include isolating compromised systems, blocking accounts, modifying firewall rules, or disconnecting network segments.

Practical examples

Rapid isolation procedures for compromised systems (network disconnection, account lockout), emergency firewall rules, endpoint quarantine tools.

What NIST requires

After containment, the root causes of the incident must be completely eradicated: malware removal, backdoor elimination, closure of exploited vulnerabilities, remediation of compromised systems. Incomplete eradication can lead to recurrence.

Practical examples

Malware removal procedures, remediation of compromised systems, closure of exploited vulnerabilities, reset of compromised credentials, verification of backdoor elimination.

What NIST requires

The recovery portion of the response plan must be activated once containment and eradication are complete. The plan must define recovery priorities based on the criticality of systems and services to the business.

Practical examples

Recovery plan with system restoration priorities, detailed procedures for restoring from backups, plan activation checklist, designated recovery team.

What NIST requires

Recovery actions must be selected, scaled, and prioritized based on business impact. The systems most critical to operations must be restored first, following a predefined order in the plan.

Practical examples

List of systems ordered by restoration priority (business criticality), estimated recovery time (RTO) for each system, resources required for recovery.

What NIST requires

Before using backups or other resources for recovery, their integrity must be verified. A backup compromised by the attacker could reintroduce the threat into freshly remediated systems.

Practical examples

Backup integrity verification procedure before restore (hashes, restore tests), anti-malware scanning of backups, use of backups from periods prior to the attack if necessary.

What NIST requires

Recovery must consider critical functions and risk management needs to define post-incident operating conditions. It may be necessary to operate with reduced functionality or additional controls while full recovery proceeds.

Practical examples

Assessment of post-incident operational conditions, possible operation in degraded mode, additional security controls during the recovery phase, communication of temporary limitations.

What NIST requires

Restored assets must be verified to ensure they are intact, functional, and free of residual compromise. Normal operation must be confirmed before a system's recovery is considered complete.

Practical examples

Post-recovery verification checklist (data integrity, service functionality, absence of residual compromise), functional testing, intensive monitoring of restored systems.

What NIST requires

Formal conclusion of recovery must be declared when all predefined criteria are met. Incident documentation must be completed, including lessons learned and recommendations for improvement.

Practical examples

Formal recovery closure criteria, final incident report (timeline, impact, actions, costs), lessons learned session, plan updates based on lessons learned.

What NIST requires

Recovery activities and progress in restoring operational capabilities must be communicated regularly to internal stakeholders (management, employees) and external stakeholders (customers, partners, authorities). Transparency during recovery maintains trust.

Practical examples

Periodic updates to management and employees on recovery status, communications to impacted customers, progress reports to partners, recovery status dashboard.

What NIST requires

Public updates on recovery after an incident must be managed carefully, using methods and messages approved by management and the legal team. Public communication must balance transparency, accountability, and organizational protection.

Practical examples

Press release or website update approved by legal and management, pre-approved public communication strategy, designated spokesperson.