CISA Domain 5: Protection of Information Assets — Free Visual Study Notes

Information security governance uses a layered document hierarchy to translate senior management intent into technical controls. At the top, security policies articulate management's commitment and high-level requirements for protecting information assets. Frameworks, such as ISO 27001 or the NIST Cybersecurity Framework, provide a structured approach for organizing security controls and processes. Standards specify mandatory technical requirements that implement policy—for example, minimum encryption key length or password complexity rules. Guidelines offer advisory, best-practice recommendations for how to implement standards in specific contexts. Each lower layer becomes more specific and technical. The hierarchy ensures that board-level security intent flows down to the individuals and systems responsible for implementing controls. The IS auditor verifies that all layers exist, are consistent with each other, and are actively enforced.

Information security documentation operates in a three-layer hierarchy. At the top, the information security policy is a management-approved statement that defines the organization's security intent, assigns responsibility, and sets the tone for compliance. Below the policy, procedures provide step-by-step operational instructions — covering specific tasks such as user onboarding, incident escalation, or backup verification. At the base, guidelines offer advisory recommendations that users may adapt to their context without mandatory compliance. IS auditors evaluate whether each layer exists, is current (recently reviewed), is approved by appropriate authority, and aligns with the current risk environment. The absence of a signed policy is a material finding; outdated procedures that reference decommissioned systems or obsolete regulations are also reportable.

An information security standard is a set of mandatory rules that specify exactly how security must be implemented across an organization. Standards ensure consistency: every system, team, and vendor follows the same requirements, ensuring that specific technologies, applications, and procedures are implemented uniformly. An information security framework is a set of processes that define the policies and procedures necessary for the successful implementation and ongoing management of an information security program. Frameworks help organizations manage risk, reduce vulnerabilities, and prioritize security tasks. Because frameworks often overlap, organizations map multiple frameworks together to avoid duplicate effort while ensuring comprehensive coverage. From an auditor's perspective, the absence of a documented framework means the security program lacks governing policies and procedures, while the absence of standards means controls are applied inconsistently.

An information security baseline is a documented set of minimum security configurations that every system, network device, or endpoint of a given type must meet. Baselines are derived from industry standards — such as CIS Benchmarks, NIST guidelines, or vendor hardening guides — and adapted to the organization's environment. They address settings like password complexity, service enablement, port configurations, encryption requirements, and account controls. Baselines function as the floor: any configuration below baseline is non-compliant, regardless of operational convenience. IS auditors evaluate whether formal baselines exist for each asset class, whether all assets are periodically measured against them, and whether deviations are tracked with formal risk-acceptance or compensating controls. An undocumented deviation is always a finding.

Physical and environmental security forms the outer defense layer for all information assets. Physical controls restrict and monitor access to facilities, equipment, and media — including badge readers, mantrap entries, biometric locks, surveillance cameras, and security guards. Environmental controls protect infrastructure from non-human hazards: fire suppression systems and smoke detectors guard against fire; raised flooring and flood sensors address water damage; uninterruptible power supplies and generators address power failure; HVAC monitoring maintains safe operating temperatures; and shielding or grounding controls electromagnetic interference. IS auditors must evaluate both control categories even when, as is typical, environmental controls are owned and operated by facility management rather than the information security function. Coordination gaps between the two teams are a frequent audit finding.

IT infrastructure faces five major categories of environmental threat, each requiring specific mitigating controls. Fire is the most severe — computer rooms require gaseous suppression agents (halon alternatives or inert gas systems), smoke and heat detectors, and clear evacuation routes; water-based sprinklers are inappropriate near computing equipment. Water and flooding are mitigated by raised equipment platforms, moisture and leak sensors, and siting server rooms above flood-prone areas. Power threats — surges, outages, and sags — are addressed by uninterruptible power supplies, automatic transfer to backup generators, power conditioning, and surge protection devices. Temperature instability is managed with monitored HVAC systems and redundant cooling to prevent equipment overheating. Electromagnetic interference, from nearby electrical equipment or external sources, is controlled through cable shielding and proper grounding of all IT equipment. IS auditors sample inspection records and test documentation for each category.

Physical access exposures arise when unauthorized individuals gain entry to facilities housing information systems, equipment, or sensitive documents. Exposures include unauthorized entry, vandalism, theft of equipment or documents, copying or viewing of sensitive information, alteration of equipment, and wiretapping. Perpetrators fall into three categories: insiders with authorized access who become threats (disgruntled employees, those facing termination, or those under financial stress), other insiders without proper access, and outsiders such as former employees, competitors, or organized criminals. Controls an IS auditor evaluates include: adequacy of forced-entry protection, key and badge management, visitor escort requirements, CCTV and alarm systems, and the completeness of the leaver process for revoking physical credentials. The most likely source of exposure is the uninformed, accidental or unknowing person, but the greatest impact typically comes from malicious or fraudulent insiders.

Physical security in industrial settings differs from office environments because the assets being protected aren't just data — they're production systems. ICS/SCADA controls operational technology, and a security failure here can cause physical harm or operational outage. Industrial control systems (ICS) are used to manage and automate physical infrastructure such as power grids, water treatment, transportation networks, and industrial manufacturing. The four primary ICS component types are: SCADA (Supervisory Control and Data Acquisition), which provides high-level monitoring and control across wide geographic areas; PLCs (Programmable Logic Controllers), hardened field devices that execute specific automated logic sequences; RTUs (Remote Terminal Units), remote sensors that collect field data and relay it to the central SCADA system; and HMIs (Human-Machine Interfaces), the operator-facing screens used to monitor system status and issue commands. ICS security differs from conventional IT security in three critical ways: availability and physical safety are the primary objectives (not confidentiality); patching timelines are dictated by operational windows that may occur infrequently; and many ICS protocols (Modbus, DNP3) were designed without built-in authentication or encryption. IS auditors must assess compensating controls — primarily network segmentation and dedicated ICS monitoring — when direct patching is infeasible.

Identity and access management (IAM) is a framework of policies, processes, and technologies that governs how user identities are created, maintained, and retired across an organization's systems. An effective IAM program addresses four functional areas:

1. provisioning and lifecycle management — ensuring accounts are created with least privilege and deprovisioned promptly when no longer needed
2. compliance and regulatory alignment — implementing controls and producing audit evidence to satisfy SOX, GLBA, and other applicable frameworks
3. security incident monitoring and analysis — using SIEM tools and log correlation to detect and respond to suspicious access events; and
4. vendor and third-party risk — extending IAM obligations contractually to outside parties with system access

IS auditors evaluate each function for design adequacy and operating effectiveness.

Identity and access management (IAM) is a structured framework of policies, processes, and technologies that governs how digital identities are created, used, and retired within an organization. The user access lifecycle moves through four sequential stages. Provisioning establishes an account with role-appropriate permissions, using formal request and approval workflows. Authentication verifies identity at login through credentials, tokens, biometrics, or multi-factor combinations. Authorization determines what the authenticated user is permitted to access and do, enforced through role-based or attribute-based access control. Deprovisioning disables or removes accounts and access rights when employment ends or roles change. IS auditors evaluate each stage for adequacy of design and timeliness of operation — focusing especially on stale account detection (deprovisioning) and over-privileged account identification (authorization), which represent the most common control failures in IAM environments.

Authentication, authorization, and accountability (AAA) are three interdependent principles that together enable secure and auditable access to information systems. Authentication is the process of verifying a claimed identity — confirming that a user is who they say they are, using credentials based on knowledge (passwords), possession (hardware tokens), or inherence (biometrics). Authorization follows successful authentication and determines what resources and operations the verified identity is permitted to access, typically governed by role-based access control (RBAC) or similar models. Accountability is the recording of all user actions in tamper-resistant audit logs, enabling after-the-fact reconstruction of events, detection of policy violations, and evidence preservation for legal or disciplinary proceedings. The three principles are sequential: authentication gates authorization, and accountability logs the result. IS auditors evaluate whether logging covers all access events, whether logs are protected from modification, and whether log retention meets regulatory requirements.

Zero-trust architecture (ZTA) is a cybersecurity framework that replaces the assumption of implicit trust for users and devices inside the corporate network with continuous, explicit verification for every access request. The traditional perimeter security model assumes that anything inside the firewall is trustworthy — an assumption that fails when credentials are compromised or attackers gain physical or logical access to the internal network. ZTA applies three controls to every resource access request: first, identity verification requires the requesting user to authenticate, typically with multi-factor authentication; second, device posture validation confirms that the requesting endpoint meets security baseline requirements such as OS patch level, endpoint detection and response enrollment, and compliant configuration; third, least-privilege enforcement grants access only to the specific resource needed, not to the broader network segment. ZTA significantly reduces the blast radius of credential compromise because lateral movement within the network requires repeated, independent authorization at each resource boundary.

Privileged access management (PAM) is the discipline of controlling, monitoring, and auditing the use of elevated system permissions — administrator, root, service, and shared accounts that can bypass normal access controls. PAM programs address four operational domains. Discovery involves identifying every privileged account in the environment, including those created by applications, legacy migrations, or shadow IT — undiscovered accounts are unmanaged risk. Vaulting stores privileged credentials in an encrypted, access-controlled repository (a privilege vault), eliminating shared password spreadsheets and enabling automated credential rotation. Session control records privileged user activity in real time, enabling both live monitoring and forensic replay after incidents. Audit and review periodically certifies that each privileged account still requires its level of access, and implements just-in-time (JIT) elevation as an alternative to standing administrative access. IS auditors evaluate whether all four domains are implemented and whether PAM controls are tested regularly.

A directory service is a specialized database that stores and maintains information about users, groups, computers, and other network resources. It serves as the central authority for identity authentication and access authorization across an organization's environment. Common examples include Microsoft Active Directory and OpenLDAP. IS auditors evaluate directory services across three control dimensions. Identity storage controls ensure that directory records reflect only current, authorized users — stale accounts from terminated employees or expired contractors are unauthorized access vectors and must be identified and removed. Access privilege management controls ensure that users and service accounts hold only the minimum privileges required for their function — over-privileged accounts, especially those with domain administrator rights, are high-risk audit findings. Change auditing controls ensure that all modifications to the directory — account creation, privilege escalation, group membership changes — are logged, protected from modification, and periodically reviewed for unauthorized changes. Directory services are high-value attack targets and require correspondingly rigorous controls.

Identity governance and administration (IGA) is the discipline of systematically managing, reviewing, and enforcing access rights to ensure that users — including employees, contractors, and vendors — hold only the access they need, with evidence produced for audit purposes. IGA operates across three primary functions. Access certification is the periodic campaign in which managers review and formally confirm each user's current access rights; uncertified or revoked access is removed. This process surfaces privilege accumulation — where users collect access rights over time through role changes without losing old entitlements. Segregation of duties (SoD) enforcement uses automated rules to identify and prevent role combinations that create fraud risk, such as the ability to both initiate and approve financial transactions. External party governance tracks access granted to third parties — consultants, vendors, business partners — ensuring that access is formally documented, time-limited, and subject to contractual security requirements. IS auditors rely on IGA-produced reports — certification completion rates, SoD violation logs, external access inventories — as primary evidence of access control operating effectiveness.

Identity as a Service (IDaaS) delivers IAM capabilities through the cloud on a subscription basis. Organizations use IDaaS to outsource operational identity tasks — creating user accounts, authenticating access requests, and governing access — to a third-party provider. For security effectiveness, an IDaaS solution should support five core capabilities: single sign-on (SSO), multi-factor authentication (MFA), user identity management, access provisioning, and cloud directory services. Within IDaaS, two distinct functions must be clearly separated. Identity administration (IA) handles operational activities: provisioning accounts, resetting passwords, and assigning initial access. Identity governance (IG) handles oversight: conducting access reviews, enforcing separation of duties (SoD), implementing role-based access control (RBAC), and generating analytics and reports for compliance visibility. An IS auditor reviewing an IDaaS arrangement must confirm that both functions are present, clearly delineated, and subject to audit rights.

System access permission is the technical privilege granted to a subject — a user or process — to act on a resource: reading, writing, modifying, or deleting data, executing a program, or making an external connection. All access to computerized information must be justified by a documented need-to-know and governed by the principle of least privilege, meaning access is granted only to the minimum required to perform a defined function. Logical access controls are organized across four layers: the network layer (controls who can reach systems at all), the platform layer (controls operating-system and system-software access), the database layer (controls table, row, and column-level data access), and the application layer (controls transaction and function-level access within a specific application). Each layer adds granularity. An IS auditor evaluates all four independently, because a gap at any single layer can be exploited even when the others are secure.

Access controls regulate who can read, write, or execute computer resources. Three primary models are tested on the CISA exam. Mandatory access control (MAC) uses sensitivity labels set by an administrator; users and even data owners cannot override the policy. Anything not expressly permitted is forbidden, making MAC appropriate for highly sensitive environments. Discretionary access control (DAC) allows the data owner to define who accesses the resource and at what level. DAC acts as an additional filter that further restricts access but cannot override MAC restrictions. Role-based access control (RBAC) grants access based on a user's job role rather than individual identity, reducing unnecessary access to sensitive data and simplifying administration. In practice, organizations layer these: MAC enforces classification boundaries, DAC allows owner-defined sharing within those boundaries, and RBAC simplifies provisioning by assigning users to predefined roles.

When external parties — vendors, contractors, consultants, outsourced service providers — need access to an organization's information or information processing facilities, the organization's security posture must not be diminished by that access. Before any access is granted, the organization must perform a risk assessment that considers: what facilities or data the external party will access; whether the access is physical (offices, server rooms) or logical (databases, systems); network connectivity requirements; and the regulatory classification of the information involved. Based on this assessment, specific controls are defined and agreed upon in a formal contract or service agreement. Organizations must also retain the right to audit the external party's security controls — without this right, there is no means to verify compliance with the agreed-upon controls. The absence of a pre-access risk assessment or missing audit rights clause in a vendor contract are both audit findings.

Digital rights management (DRM) is a technology framework that enforces usage restrictions on digital content and information assets beyond the point of initial access authorization. Standard access controls determine who can open or download a file; DRM determines what the recipient can do with the file after opening it. DRM controls operate across three categories. Copy control prevents duplication of protected content, including clipboard copying and file-level duplication. Distribution control restricts forwarding, email attachment, and sharing of documents to recipients who are not authorized by the rights holder. Usage restrictions limit specific operations such as printing, screen capture, time-limited viewing, or conversion to unprotected formats. DRM is implemented through software agents embedded in documents or media files and enforced through a rights management server that validates permissions before allowing each operation. IS auditors evaluate DRM deployment for high-sensitivity content categories, the technical enforceability of controls, and exception handling for legitimate operational needs.

Logical access is the ability to interact with information systems and data, granted through the mechanisms of identification, authentication, and authorization. Logical access controls are the primary means of protecting information assets and encompass four analytical dimensions. Entry points are all the interfaces through which users or systems can access resources — application login screens, API endpoints, database connections, remote access portals, and network management consoles. Each entry point requires appropriate authentication and authorization controls. Access exposures are vulnerabilities created by weak logical access design, including shared user accounts, excessive privilege assignment, orphaned or dormant accounts, and unmonitored or undocumented access paths. Control mechanisms are the technical implementations that enforce access policy — role-based access control, access control lists, session timeout policies, MFA enforcement, and privileged access management. IS auditors evaluate whether controls are designed and operating effectively at each entry point, exposures are identified and addressed, and access logs are complete, protected, and regularly reviewed for violations.

Access control software is the technical mechanism that enforces user authorization decisions within information systems, ensuring that authenticated users can only perform operations and access resources that their permission profile permits. Access control software operates across three functional layers. The user authorization layer maintains permission tables, access control lists, or role mappings that define precisely which users or groups are authorized to access which system resources at which access level — tables must be kept current as roles and organizational structures change. The resource protection layer enforces authorization decisions in real time at the point of each resource request, blocking unauthorized operations and allowing only those explicitly permitted. The audit and reporting layer logs all access events — particularly failed access attempts, which are the primary indicator of brute-force attacks, unauthorized access probing, or insider threat activity — and generates compliance reports for management review and regulatory submissions. IS auditors evaluate all three layers, with particular focus on permission table currency, failed-attempt logging completeness, and the availability of audit reports.

Logon IDs and passwords are the foundational components of knowledge-based user authentication. A logon ID uniquely identifies a user to the system; it should be unique per user, follow a consistent naming convention, and not reveal sensitive organizational information. Passwords authenticate the claimed identity by matching a stored (hashed) credential. Password controls address four dimensions. Logon ID controls require unique IDs, prohibit sharing, and enforce naming conventions. Password strength controls specify minimum length, character complexity (uppercase, lowercase, digits, special characters), maximum age (expiry forcing periodic changes), and history (preventing reuse of recent passwords). Password attack methods include dictionary attacks (testing known words and common patterns), brute-force attacks (exhaustive character-space enumeration), rainbow table attacks (using precomputed hash-to-plaintext mappings), and social engineering or phishing to harvest credentials directly. Account controls mitigate attacks by enforcing lockout after a defined number of failed attempts, CAPTCHA mechanisms, and alerting on repeated failure patterns. IS auditors evaluate all four dimensions and assess whether multi-factor authentication compensates for password weaknesses in high-risk contexts.

Remote access security encompasses the controls required to protect organizational systems when users, employees, vendors, consultants, or business partners connect from locations outside the corporate network perimeter. Organizations support multiple remote access mechanisms: VPN (virtual private network) connections that extend the corporate network over encrypted tunnels; remote desktop protocols such as RDP or virtual desktop infrastructure (VDI) that provide graphical access to internal systems; SSH for encrypted administrative command-line access; and web-based application portals for browser-based access to specific applications. Security controls for remote access operate across three dimensions. Authentication controls require multi-factor authentication as the minimum for all remote connections, with third-party and vendor access limited to the specific systems and time windows required. Monitoring controls include session logging for all remote connections, session recording for privileged remote access, and anomaly detection alerts for unusual connection times, geolocation, or data transfer volumes. Endpoint posture controls validate that connecting devices meet minimum security requirements — patch level, EDR enrollment, and configuration compliance — before allowing access, particularly for BYOD and personal devices.

Biometric authentication controls access to systems or facilities based on a user's unique measurable physical or behavioral characteristics — fingerprints, iris patterns, retinal scans, facial geometry, voice patterns, or handwriting dynamics. The biometric process operates in two phases: enrollment, where the user's biometric characteristic is captured and converted into a mathematical template stored securely in the system; and verification, where a new biometric sample is compared to the stored template to confirm identity. IS auditors evaluate biometric systems using two key error rate metrics. The False Accept Rate (FAR) measures the probability that an unauthorized individual is incorrectly granted access — a high FAR represents a direct security risk. The False Reject Rate (FRR) measures the probability that an authorized user is incorrectly denied access — a high FRR represents an operational friction problem. These two rates are inversely related: tuning the system to reduce FRR (more permissive) increases FAR (less secure), and vice versa. The Equal Error Rate (EER), also called the Crossover Error Rate (CER), is the threshold where FAR equals FRR and is the primary single-number benchmark for comparing biometric system accuracy. Lower EER indicates a more accurate system. IS auditors also evaluate template storage security, enrollment procedure integrity, and fallback authentication for cases where biometrics fail.

Naming conventions for logical access controls are standardized rules that govern how user logon IDs, system accounts, service accounts, and access rules are labeled within access control and directory systems. A well-designed naming convention encodes meaningful information directly into the account name — such as department, role, or account type — enabling administrators and auditors to classify accounts, identify owners, and detect anomalies without requiring supplementary lookups. Consistent naming supports three operational objectives. Logon ID conventions allow rapid identification of account ownership and function, simplifying access reviews and orphaned-account detection. Access rule structures use parallel naming to map roles to resources in human-readable form, enabling faster validation during audits. Administration benefits include streamlined provisioning, consistent periodic access reviews, and reliable identification of unauthorized or legacy accounts that do not conform to the convention. IS auditors evaluate whether a naming standard exists, is enforced consistently across all systems, and whether accounts that deviate from the standard are investigated and resolved.

Federated identity management (FIM) is an arrangement between multiple organizations that allows users to authenticate once at their home Identity Provider (IdP) and access resources at partner Service Providers (SPs) using a trusted identity assertion — eliminating the need for separate credentials at each SP. The federation architecture has three components. The Identity Provider (IdP) is the authoritative source of user identity; it authenticates the user and generates a signed identity assertion. The Federation Protocol — most commonly SAML 2.0, OAuth 2.0, or OpenID Connect (OIDC) — defines the secure, standardized format for transmitting the identity assertion between IdP and SP. The Service Provider (SP) receives and validates the identity assertion from the IdP and grants access based on the asserted attributes. IS auditors evaluate FIM arrangements for two primary risk categories: trust inheritance risk, where the SP accepts IdP identity claims without independent verification, making the SP's security dependent on the IdP's control strength; and session management risk, where federated sessions may outlive the SP's intended timeout or survive user termination at the IdP. Audit procedures include reviewing the federation agreement, protocol configuration, token lifetime settings, and forced-logout (single logout) capability.

When evaluating logical access controls, the IS auditor follows a four-stage systematic process. The first stage is risk understanding: the auditor reviews relevant documentation, conducts interviews, performs observation, and applies risk assessment techniques to gain a comprehensive understanding of the security risks facing information processing — this stage determines the audit's scope and the materiality thresholds for findings. The second stage is control documentation: the auditor documents and evaluates the controls governing each significant access path, including policies, procedures, technical configurations, and access rule structures, to establish what controls are designed to exist. The third stage is access path evaluation: the auditor tests each documented access path — application entry points, database connections, remote access portals, API interfaces — to verify that authentication, authorization, and audit logging controls are operating as designed. The fourth stage is violation review: the auditor analyzes security event logs, failed access attempt reports, and anomaly detection outputs to identify control failures, unauthorized access attempts, or patterns indicative of insider threat. Each stage informs the next, and the overall opinion on logical access adequacy rests on all four stages combined.

Network and endpoint security encompasses the controls that protect an organization's information assets against attacks delivered via network connectivity. The discipline addresses two complementary layers. Perimeter security controls operate at the boundaries between trusted internal networks and untrusted external networks — primarily the internet. Firewalls inspect and filter network traffic based on rules; intrusion detection systems monitor traffic for attack signatures and anomalies; these controls provide protection and alert information at the network border. Endpoint security controls protect the individual devices — workstations, laptops, servers, and mobile devices — that connect to the network. Endpoint controls include endpoint detection and response (EDR) agents, antimalware software, host-based firewalls, and patch management processes. The two layers are complementary: perimeter controls address network-level attacks but cannot inspect all internal traffic or protect unmanaged devices; endpoint controls address device-level threats but cannot detect network reconnaissance or lateral movement at scale. IS auditors evaluate both layers for design adequacy and operating effectiveness, with particular focus on the integration between them and coverage of remote and mobile endpoints.

IS network infrastructure provides the physical and logical foundation for sharing information resources across an organization's computing environment. Networks rely on telecommunications links to carry data between devices. Two primary categories of telecommunications links exist. Digital links transmit data as discrete binary signals over dedicated circuits — including leased lines, fiber optic connections, and digital subscriber line technologies. Digital links offer high bandwidth, low error rates, and deterministic performance characteristics that make them the standard for IS network infrastructure. Analog links transmit data as continuous electrical waveforms over the traditional public switched telephone network (PSTN), requiring modems to convert between digital and analog formats at each end. Analog links have significantly higher error rates, lower throughput, and variable performance; they are appropriate only as emergency backup connections when digital alternatives are unavailable. IS auditors evaluate network infrastructure for capacity adequacy relative to business requirements, redundancy to support continuity objectives, and security of data in transit across external telecommunications links — particularly whether sensitive data is encrypted end-to-end.

Modern enterprise network architectures provide the structural foundation for all IS network security controls. Contemporary enterprise networks are large, centrally managed, high-speed environments built on client-server computing models, in which clients request services and dedicated servers provide them. The defining architectural principle is the clustering of IT functions into dedicated network segments — grouping systems with similar functions, data sensitivity levels, or user populations into logical network zones, each with its own security policies and access controls. This approach delivers three key properties. Client-server architecture enables efficient resource sharing and centralized application management. Network segmentation limits lateral movement by preventing unrestricted communication between segments — a compromise in one segment cannot automatically propagate to others. Centralized network management enables consistent policy deployment, configuration management, and monitoring across all segments from a unified control plane. IS auditors evaluate enterprise network architecture for the completeness and logical soundness of segmentation, the enforcement of inter-segment access controls, and the isolation of management interfaces from production traffic.

IS networks are categorized by geographic scope and functional purpose, with five primary types relevant to enterprise environments. A Personal Area Network (PAN) is the smallest network type, connecting an individual's personal devices — smartphones, Bluetooth headsets, smartwatches — within a range of approximately ten meters. A Local Area Network (LAN) connects devices within a single building or campus, typically using Ethernet cabling or Wi-Fi, and is the foundational network for daily office operations. A Metropolitan Area Network (MAN) spans a city or metropolitan area, connecting multiple buildings or campuses across distances of several miles — commonly used for university campuses or linking corporate headquarters to a nearby disaster recovery site. A Wide Area Network (WAN) spans cities, countries, or continents, providing connectivity between geographically dispersed locations through leased lines, MPLS, or internet-based VPN. A Storage Area Network (SAN) is a specialized, high-speed network dedicated exclusively to connecting servers with storage devices, optimized for high-throughput block-level data access. IS auditors document the network types in scope, evaluate the security controls at each boundary between types, and verify that appropriate monitoring and encryption are applied based on the sensitivity of data traversing each network.

Network services are the functional capabilities made available by operating system applications running on servers that enable orderly use of network resources. IS auditors evaluate four core network services for security. DHCP (Dynamic Host Configuration Protocol) dynamically assigns IP addresses, subnet masks, and gateway information to network devices. A rogue DHCP server — an unauthorized device advertising DHCP responses — can redirect client traffic through attacker-controlled infrastructure; the primary control is DHCP snooping, which limits DHCP server responses to approved switch ports. DNS (Domain Name System) translates hostnames to IP addresses, enabling users to access services by name. DNS cache poisoning inserts false records into a DNS resolver's cache, redirecting users to malicious sites; controls include DNSSEC validation, response rate limiting, and anomaly monitoring. Print services enable shared access to printers across the network; unencrypted print traffic may expose sensitive document content, and unrestricted print queue access allows data exfiltration through physical output. Directory services store and serve identity and access data across the organization; compromise of directory services affects all downstream authentication and authorization decisions. IS auditors verify that each service is hardened against its primary attack vector and subject to active monitoring.

Network standards and protocols establish the rules that allow devices from different vendors and platforms to communicate reliably in heterogeneous environments. Two reference models are foundational to IS audit work. The OSI (Open Systems Interconnection) model divides network communication into seven functional layers: Physical (electrical signals and cables), Data Link (MAC addressing, switching), Network (IP addressing, routing), Transport (TCP/UDP, port numbers, flow control), Session (session establishment and management), Presentation (data formatting and encryption negotiation), and Application (protocols used by applications — HTTP, SMTP, FTP). The TCP/IP model consolidates these into four layers: Network Access (combining Physical and Data Link), Internet (IP), Transport (TCP/UDP), and Application. IS auditors use these models to specify precisely where a security control operates and what it can detect. A firewall operating at Layer 3-4 filters based on IP addresses and port numbers but cannot inspect application content. A next-generation firewall or application-layer proxy operating at Layer 7 can inspect packet payloads, identify specific applications, and detect application-layer attacks such as SQL injection or protocol anomalies. Matching control layer to threat layer is a key audit evaluation criterion.

A VPN (Virtual Private Network) extends the corporate network securely to remote users and locations by creating an encrypted tunnel over the public internet, allowing encrypted packets to be transmitted as though the remote user were physically on the corporate network. VPNs are deployed in two primary configurations. A site-to-site VPN connects two fixed network locations — such as a headquarters and a disaster recovery site — using permanently established IPSec tunnels; the connection is transparent to users on either network. A client-to-site VPN enables individual remote users to connect to the corporate network using VPN client software on their endpoint, commonly using SSL/TLS or IPSec protocols. The critical configuration decision is split tunneling: when enabled, only corporate-destined traffic flows through the VPN while internet-bound traffic is routed directly to the internet, bypassing the organization's firewall, content inspection, and DLP controls. This creates a security gap in which malware or attacker tools on the endpoint can communicate freely with external infrastructure. Full-tunnel VPN forces all traffic through the corporate security stack, eliminating this bypass. IS auditors evaluate VPN protocol strength (IPSec with AES-256 is current standard; PPTP is deprecated), MFA requirements for VPN authentication, split-tunneling configuration, and server certificate validation.

Network Attached Storage (NAS) is a centralized file server that enables multiple users to store and share files across a network. Securing NAS environments is critical for compliance with data protection laws, protecting proprietary data, and preventing theft and outages. IS auditors should be aware of six NAS vulnerability categories identified in the source. First, unsecure network configurations: NAS devices on open or inadequately segmented networks are exposed to all threats on that network; unencrypted sessions add further risk. Second, unsecure passwords: shared, unencrypted, or improperly stored credentials enable unauthorized access. Third, insufficient authentication: NAS systems without identity verification requirements allow attackers who reach the network to access storage directly. Fourth, leakage from other network devices: NAS devices connected to IoT devices are at risk because IoT devices can leak malware into the NAS infrastructure, infecting NAS-connected devices. Fifth, exposure to malware: NAS can be exposed to malware including worms, viruses, and ransomware, which use poorly secured NAS and IoT-enabled devices as attack vectors. Sixth, command injection: attackers can exploit NAS susceptibility to command injection to take control of storage drives and sometimes gain root access. Controls include network segmentation, encrypted credentials stored in a secrets vault, MFA for NAS administration, and a documented patch-management schedule.

A content delivery network (CDN) is a distributed network of geographically dispersed servers — called edge nodes or points of presence — that cache and serve web content from locations close to end users. The architecture has three components: an origin server that holds the authoritative content, CDN edge nodes that cache and serve copies of that content, and end users who receive content from the nearest edge node. CDNs improve performance (by reducing distance-related latency) and availability (by distributing load and providing DDoS absorption capacity). IS auditors evaluate four CDN security considerations. Cache poisoning occurs when an attacker manipulates the content stored in CDN edge caches to serve malicious or incorrect content to users. Sensitive data leakage arises when cache-control headers are misconfigured, causing authenticated or personalized content — account details, session tokens — to be cached and served to unintended users. TLS inspection risk exists because CDNs terminate HTTPS connections at edge nodes and re-establish them to the origin, placing the CDN provider in a position to inspect plaintext content. DDoS mitigation is a security benefit of CDNs, which can absorb large volumetric attacks before they reach the origin server. Auditors verify cache-control header configurations, CDN provider security certifications, and contractual obligations regarding data handling.

Network Time Protocol (NTP) is a UDP-based protocol that synchronizes the clocks of network devices by referencing a hierarchy of time sources, ultimately traceable to an authoritative stratum-0 source such as a GPS receiver or atomic clock. In IS security environments, accurate and synchronized timestamps are critical for two primary functions. Log correlation and forensic analysis require all devices — firewalls, servers, endpoints, SIEM — to share a common time reference; even a few minutes of clock skew between systems makes it impossible to accurately reconstruct the sequence of events during a security incident, degrading the evidentiary value of all logs. Time-based access controls — including Kerberos ticket authentication and TOTP (time-based one-time passwords) — require clock synchronization within strict tolerances, typically five minutes or less; devices outside this tolerance may be unable to authenticate. NTP itself introduces security risks: NTP spoofing attacks can manipulate device clocks to disrupt time-based controls or corrupt log ordering. IS auditors verify that all devices are configured to use a common, trusted NTP source; that NTP server configuration is reviewed periodically; and that clock drift monitoring is in place to detect synchronization failures before they affect forensic integrity.

Networked applications are delivered through several architectural models, each with distinct security implications. In client-server architecture, processing is distributed between a central server and client machines. Thick clients perform significant processing locally, making endpoint security and patching critical. Thin clients delegate most processing to the server, concentrating security requirements there. Web-based applications use standard internet protocols and browsers as thin clients, requiring robust server configuration, encrypted communications (HTTPS/TLS), and protection against web application attacks. Service-oriented architecture (SOA) decomposes functionality into independent, reusable services accessed via standard interfaces; security must be enforced at every service boundary and interface. An IS auditor evaluating any networked application must match the security controls to the architecture: where data is processed determines where the highest-risk controls must be applied.

Network infrastructure security encompasses the controls applied to the communication devices — routers, switches, network control terminals, and their management systems — that form the backbone of an organization's network. IS auditors evaluate infrastructure security across three control domains. Network control terminal security requires that management interfaces — the administrative consoles used to configure and manage network devices — are accessible only through encrypted protocols (SSH for CLI, HTTPS for web interfaces; Telnet and HTTP are unacceptable), physically or logically restricted to authorized administrators, and ideally accessible only from a dedicated out-of-band management network segment that is isolated from user and production traffic. Traffic and protocol controls define the acceptable use of the network, enforce restrictions on unauthorized protocols, filter traffic at layer 3-4 and layer 7 based on policy, and establish traffic baselines that enable anomaly detection. Infrastructure monitoring involves continuously monitoring network security events — configuration changes, management access, anomalous traffic patterns, and protocol violations — and generating alerts and logs for IS audit use. IS auditors verify that infrastructure monitoring is security-focused (not merely performance-focused), that management access is logged and reviewed, and that configuration change management applies to all network devices.

A firewall is a network security control that inspects and filters traffic between network segments based on defined security policies. Four firewall types represent progressively deeper inspection capabilities. Packet filter firewalls apply rule-based decisions using source and destination IP addresses, port numbers, and protocol type — they are fast but cannot detect attacks hidden within valid-looking packets. Stateful inspection firewalls track the state of each network connection and verify that packets belong to an established, permitted session, blocking unsolicited traffic that packet filters would pass; however, they cannot inspect application-layer content. Application proxy firewalls (application gateways) terminate and rebuild connections at the application layer, inspecting the full content payload for protocol compliance and malicious content — they provide the deepest inspection of traditional firewall types but introduce higher latency. Next-generation firewalls (NGFW) combine stateful inspection with deep packet inspection, application identification regardless of port, user-identity-based policy enforcement, and integrated threat intelligence feeds. IS auditors evaluate firewall rule sets for overly permissive rules (particularly 'permit any any'), unauthorized rule additions, rule redundancy, and the frequency and completeness of rule review processes.

Unified threat management (UTM) is a network security approach in which multiple security functions are consolidated into a single appliance or software platform, providing a unified management interface. UTM solutions typically combine five primary security functions: antivirus scanning detects and blocks malware at the network gateway before it reaches endpoints; anti-spam filtering identifies and quarantines unsolicited or malicious email; intrusion prevention (IPS) inspects traffic for known attack signatures and blocks matching traffic in real time; content filtering controls web access by categorizing URLs and blocking access to prohibited or malicious sites; and sandboxing executes suspicious files or code in an isolated environment to observe behavior and detect previously unknown malware before it reaches the network. UTM simplifies security management for smaller organizations and branch offices by reducing the number of devices and management consoles. IS auditors evaluate UTM deployments for two primary risks: single point of failure, where the failure or bypass of the UTM eliminates all consolidated security functions simultaneously; and performance bottleneck, where high traffic volumes can overwhelm a single-device architecture. Auditors also verify that UTM signatures and software are kept current and that high-availability configurations exist for critical deployments.

Network segmentation is the practice of dividing a single flat network into multiple isolated zones — each with its own security policies, access controls, and monitoring — to reduce the risk of lateral movement following an initial compromise. A flat network provides no internal barriers: an attacker who gains access to one device can typically reach all other devices on the network. Segmented networks apply four complementary concepts. Security zones group systems with similar risk profiles and data sensitivity into logically distinct network areas — common zones include production internal, DMZ, development, management, and guest wireless. Inter-segment controls — firewalls, router ACLs, and network access control systems — filter all traffic that attempts to cross zone boundaries, enforcing the policy that each zone applies to traffic from other zones. DMZ (demilitarized zone) architecture places internet-facing servers in an intermediate zone between the external internet and the internal trusted network, ensuring that a compromised public server cannot directly reach internal systems without traversing additional security controls. Micro-segmentation extends the segmentation principle to individual workloads, virtual machines, or containers — commonly implemented in cloud environments using software-defined networking and applied policies at the application level. IS auditors evaluate whether zone definitions are logically justified by data sensitivity and risk, inter-segment controls are configured and periodically tested, and no unauthorized paths between zones exist.

Endpoint security refers to the security controls applied to individual devices — workstations, laptops, servers, and mobile endpoints — that connect to an organization's network. Four primary endpoint controls form a layered defense. Antimalware software uses signature-based detection to identify known malicious files by comparing them against a database of threat signatures; it is effective against known malware but cannot detect fileless attacks, zero-day exploits, or polymorphic code that changes its signature. Endpoint Detection and Response (EDR) extends protection by monitoring endpoint behavior — process execution, memory activity, network connections, and file system changes — using behavioral analysis and anomaly detection to identify threats that evade signature scanning, including fileless malware and living-off-the-land attack techniques. EDR also enables active response capabilities such as process termination, endpoint isolation, and forensic telemetry collection. Patch management ensures that endpoint operating systems and applications receive current security patches, closing known vulnerability windows before attackers can exploit them. Host-based firewalls apply network traffic filtering at the device level, restricting inbound and outbound connections based on local policy — providing protection even when the endpoint operates outside the corporate network perimeter. IS auditors evaluate endpoint controls for deployment coverage across all managed devices, signature and software currency, and patch timeliness metrics.

Data loss prevention (DLP) is a set of integrated tools and processes designed to prevent the unauthorized access to, transfer of, or exfiltration of sensitive organizational data — including confidential business information, regulated personal data, and intellectual property. An effective DLP program operates across three interdependent components. Data classification establishes the taxonomy of sensitive data — defining what is confidential, regulated, or proprietary and mapping where it resides across the organization's systems, storage, and endpoints; without accurate classification, DLP policies cannot be properly scoped and will generate excessive false positives or miss actual violations. Policy enforcement translates data classification into technical monitoring and blocking rules that operate across data in motion (network DLP), data at rest (storage scanning), and data in use (endpoint agent); policies require ongoing tuning to balance sensitivity against false positive rates. Incident response integrates DLP alerts into a structured workflow in which analysts triage violations, determine intent (accidental or malicious), escalate appropriately, and feed results back into policy improvement. IS auditors evaluate DLP programs for classification accuracy, policy tuning evidence, alert response timeliness, and the integration of DLP findings into the broader security operations function.

DLP systems are deployed in three primary configurations that correspond to different data paths and monitoring contexts. Network-based DLP systems monitor all data crossing network boundaries — typically positioned at the internet gateway, email relay, or web proxy. They scan outbound traffic for sensitive data patterns and can detect, alert on, or block transfers of regulated data via email, web upload, FTP, and similar protocols. However, network DLP cannot monitor data transferred via local removable media or actions taken entirely within the endpoint. Endpoint-based DLP agents are installed directly on individual devices and monitor actions performed on the endpoint itself — copying files to USB drives, printing sensitive documents, screen capture, and local application actions that do not generate network traffic. Endpoint DLP operates regardless of the user's network connection and is essential for detecting removable media exfiltration and actions by users on unmonitored network paths. Cloud DLP (often integrated with a Cloud Access Security Broker, or CASB) monitors data flowing to and from cloud services — detecting sensitive data uploaded to personal cloud storage, shared via cloud collaboration tools, or stored in unauthorized cloud applications. IS auditors evaluate whether the organization's DLP deployment covers all three data paths based on the assessed exfiltration risk profile, with particular attention to coverage gaps where data can exit without traversing any monitored control point.

Data loss risk encompasses the probability and impact of sensitive data being accessed by unauthorized parties, corrupted, destroyed, or stolen. Understanding the root causes of data loss is essential for designing proportionate controls. Four primary cause categories drive data loss risk. Malicious insider risk arises from employees, contractors, or privileged users who intentionally access and exfiltrate data for personal gain, competitive intelligence, or retaliation — this category is particularly dangerous because insiders already have legitimate access that bypasses perimeter controls. Accidental disclosure involves unintentional data exposure — misdirected emails, incorrectly configured sharing settings, or forgotten attachments — and is typically the highest-volume incident category in most organizations. External attack covers adversaries using technical means — malware, credential phishing, exploitation of vulnerabilities — to gain unauthorized access and exfiltrate data from the outside. Poor data practices describe the organizational conditions that make data loss easier: inadequate data classification, sensitive data on open or poorly controlled file shares, unencrypted storage, and shadow IT repositories outside the security team's visibility. IS auditors assess data loss risk by reviewing DLP incident logs, data classification completeness, access controls on sensitive data repositories, and the organization's ability to detect and respond to each cause category.

Data loss prevention solutions must address three distinct data states, each requiring different monitoring and control approaches. Data at rest refers to data stored in files, databases, cloud storage repositories, backup media, or any location where data resides when it is not being actively transmitted or processed. DLP controls for data at rest include discovery scanning to find sensitive data stored in unexpected or unauthorized locations, encryption enforcement for sensitive data repositories, and access control verification. Data in motion refers to data actively moving across a network — in email messages, web form submissions, file transfer protocols, API calls, or collaboration tool messages. DLP controls for data in motion are typically applied at the network gateway, email relay, or web proxy, inspecting outbound content for sensitive data patterns and applying block, quarantine, or alert actions. Data in use refers to data being actively accessed or processed by an application or user — on screen, in memory, or being manipulated locally on an endpoint. DLP controls for data in use operate through endpoint agents that monitor clipboard operations, print actions, screen capture, and transfers to removable media or local applications. IS auditors evaluate whether the organization's DLP solution provides coverage for all three data states and identify gaps where sensitive data transits a state without monitoring.

DLP controls are most usefully understood in terms of their operating mode. Monitor mode (also called detect or audit mode) inspects data flows and logs policy violations without taking any blocking action — the data transfer proceeds regardless of whether it violates policy. Monitor mode is appropriate during the initial deployment phase, when policy rules are being tuned to reduce false positives and establish baseline violation rates before blocking is activated. However, DLP systems permanently operated in monitor mode function only as detective controls: they document that sensitive data left the organization but do not prevent it. Block mode (also called active or enforce mode) prevents the flagged action — blocking an outbound email containing sensitive content, quarantining a file before it is copied to removable media, or denying a web upload. IS auditors evaluate the DLP deployment plan for a defined, time-bounded transition from monitor to block mode for each policy rule, with block mode activated for high-risk, high-confidence rules as soon as tuning is complete. Additional IS auditor DLP control checks include verification that sensitive repositories are protected with read-only or classification-enforced access controls, that quarantine workflows route flagged content to security review, and that DLP reports are produced and reviewed by management regularly.

DLP solutions use multiple content analysis methods to detect sensitive data in the content they monitor, with different methods suited to different types of sensitive data. Regular expression matching applies pattern formulas to identify data that follows predictable structures — such as credit card numbers, social security numbers, bank routing numbers, and other regulated identifiers — by matching digit sequences against format templates. Exact data matching (EDM) compares content against a reference fingerprint derived from a known database of sensitive records — such as a customer account database or employee records table — enabling detection of specific sensitive data even if formatting is altered or records are mixed with other content. Statistical analysis and document fingerprinting train the DLP system on samples of sensitive document types — financial models, legal agreements, source code — and use learned statistical characteristics to identify similar documents even without matching keywords or patterns. Keyword search flags any content containing defined sensitive terms — classification labels, product code names, legal terminology — and is the simplest method to implement but generates the highest false positive rates for commonly occurring terms. IS auditors evaluate the content analysis methods deployed against the types of sensitive data in scope, verifying that methods are appropriate for each data category and that multiple methods are combined where single-method coverage is insufficient.

DLP deployment follows a structured best practice sequence designed to prevent operational disruption while achieving data protection objectives. The first phase is data discovery: the organization conducts systematic scanning of all data repositories — file servers, databases, cloud storage, endpoints — to identify where sensitive data exists. Without discovery, DLP policies cannot be accurately scoped, and sensitive data in unexpected locations remains unprotected. The second phase is policy definition: the organization translates data classification categories into specific DLP policy rules, defining content analysis methods, sensitivity thresholds, and intended actions (monitor, alert, block) for each data type and channel. The third phase is the monitor phase: policies are deployed in non-blocking mode to observe actual data flows, establish a baseline of normal versus violating behavior, and identify false positives that would disrupt legitimate business operations if blocking were activated prematurely. The fourth phase is block activation: after tuning reduces false positives to acceptable levels, blocking is activated incrementally — starting with the highest-risk, highest-confidence policies. Deploying DLP in block mode without a monitor phase risks generating operational disruptions severe enough to cause stakeholders to demand the system be disabled.

DLP systems, while essential for data protection, have inherent limitations that IS auditors must account for when evaluating their overall effectiveness. False positive risk is one of the most significant operational limitations: when DLP policies flag excessive legitimate business activities as violations, security analysts experience alert fatigue and begin ignoring or auto-closing alerts — effectively disabling the DLP system's detection capability without formally turning it off. Encrypted traffic gaps arise because DLP inspects content by reading data in transit; if that traffic is encrypted using TLS, DLP cannot read the content without SSL/TLS break-and-inspect functionality deployed at the network gateway — a configuration that adds latency and requires certificate management. Image and graphic blind spots exist because standard DLP analyzes text-based content patterns; sensitive data photographed, screen-captured, or rendered as a graphic file is invisible to standard content analysis without Optical Character Recognition (OCR) capabilities. Tuning complexity represents the ongoing management burden of maintaining accurate DLP policies as business processes, data classifications, regulatory requirements, and systems evolve — organizations that under-invest in ongoing tuning see policy accuracy degrade over time. IS auditors document these limitations, verify whether compensating controls address significant gaps, and confirm that residual risk from DLP limitations is formally accepted by management.

Encryption is the process of transforming plaintext — human-readable data — into ciphertext, a coded form that is unintelligible without the corresponding decryption key. The transformation is performed by an encryption algorithm — a mathematical function — applied to the plaintext using a cryptographic key. Decryption reverses the process, applying the decryption key and algorithm to the ciphertext to recover the original plaintext. Encryption is the foundational technical control for data confidentiality: it ensures that even if data is accessed or intercepted by an unauthorized party, the content remains unintelligible without the key. Encryption may also provide integrity verification when combined with hash functions or message authentication codes. IS auditors must understand that encryption operates at multiple levels: transport-layer encryption (TLS, HTTPS, SSH) protects data while it is in transit between systems but provides no protection after the data is delivered to its destination. File-level, disk-level, or database-level encryption protects data at rest, ensuring that the content remains protected regardless of where it travels after initial access. Comprehensive data protection requires both layers: transport encryption for data in motion and content encryption for data at rest. Effective encryption also requires key management — the policies and processes for generating, distributing, protecting, rotating, and destroying cryptographic keys.

An encryption system relies on four interdependent elements that together determine the strength of its cryptographic protection. The encryption algorithm is the mathematical function that performs the transformation between plaintext and ciphertext; algorithm security depends on the mathematical complexity of reversing the transformation without the key. Current standard symmetric algorithms include AES; current standard asymmetric algorithms include RSA and ECC. Deprecated algorithms such as DES, RC4, and 3DES should be identified and replaced. The encryption key is the critical variable that parameterizes the algorithm; key security requires secure random generation, protected storage, controlled distribution, regular rotation, and secure destruction at end-of-life. The hash function generates a fixed-length digital fingerprint of data, enabling integrity verification — detecting whether data has been altered. Current standard hash functions include SHA-256 and SHA-3; MD5 and SHA-1 are deprecated due to proven collision vulnerabilities that allow two different inputs to produce the same hash, undermining integrity verification. Key length determines the computational cost of brute-force attacks; longer keys provide exponentially more protection — 256-bit AES and 4096-bit RSA represent current strong standards for high-security applications. IS auditors identify and report any use of deprecated algorithms, insufficient key lengths, or weak hash functions across the organization's encryption inventory.

Encryption of data in transit can be implemented in two fundamentally different ways. Link encryption (also referred to as online encryption) encrypts all data traversing each individual network segment or link — including both the payload and routing headers. At each intermediate node (router or switch), the data is decrypted to read the routing information needed to forward it, then re-encrypted for the next link. This means that the plaintext content is briefly accessible at each intermediate node in the transmission path; in a network operated by a single trusted entity, this may be acceptable, but in multi-party networks, each hop represents a potential exposure point. Link encryption has the advantage of hiding routing metadata within each encrypted segment, making traffic analysis more difficult. End-to-end encryption (E2EE) encrypts data at the originating endpoint and decrypts it only at the final destination endpoint — no intermediate node can access the plaintext content. However, for routers to correctly forward packets, IP and routing headers must remain in plaintext, making traffic metadata (source and destination addresses) visible to all intermediate nodes. E2EE provides stronger content confidentiality in multi-party networks but does not protect against traffic analysis. IS auditors evaluate whether the encryption approach applied to sensitive communications matches the confidentiality requirement and the trust profile of the transmission path.

Symmetric key cryptographic systems are based on a single shared secret key that performs both encryption and decryption operations — the same key that converts plaintext to ciphertext also reverses the process. Symmetric algorithms are computationally efficient and well-suited for encrypting large volumes of data, making them the standard choice for disk encryption, database encryption, backup encryption, and bulk file encryption. The current standard symmetric algorithm is AES (Advanced Encryption Standard), used in 128-bit, 192-bit, or 256-bit key variants; 256-bit AES is the recommended option for high-security applications. Deprecated symmetric algorithms include DES (56-bit, broken by brute force) and 3DES (three-key Triple DES, deprecated by NIST in 2023). The fundamental operational challenge of symmetric cryptography is key distribution: before two parties can communicate securely, they must both possess the same secret key, and the key itself must be transmitted through a secure channel. If the key is intercepted during distribution, the encryption it protects is compromised. In large organizations with many communicating parties, key management complexity grows significantly. IS auditors evaluate symmetric key management across the full lifecycle: key generation from a cryptographically secure random source, storage in a hardware security module (HSM) or approved key vault, secure distribution mechanisms, rotation schedules, and secure destruction procedures.

Public key (asymmetric) cryptography uses a mathematically linked key pair — a public key and a private key — in which data encrypted with one key can only be decrypted with the corresponding key from the same pair. The public key is freely distributed and can be shared with any party; the private key is retained exclusively by its owner and must never be shared. The two keys serve distinct purposes. For confidentiality: the sender encrypts data using the recipient's public key. Because only the recipient holds the corresponding private key, only the recipient can decrypt the ciphertext — any other party who intercepts the message cannot read it. For authentication and integrity (digital signatures): the signer applies their private key to the data (or its hash), producing a digital signature. Any party with the signer's public key can verify the signature, confirming that it was produced by the holder of the private key and that the signed data has not been altered. Asymmetric algorithms — primarily RSA and ECC — are computationally more expensive than symmetric algorithms and are therefore used for key exchange and signing, while symmetric algorithms handle bulk data encryption in practice. IS auditors evaluate asymmetric cryptography controls in the context of certificate-based authentication, digital signature implementations, TLS handshake key exchange, and private key protection mechanisms.

Elliptic curve cryptography (ECC) is an approach to public key cryptography based on the algebraic structure of elliptic curves over finite fields. ECC provides all the capabilities of traditional asymmetric cryptography — encryption, digital signatures, and key exchange — but achieves these with significantly shorter key lengths compared to RSA. The mathematical relationship that defines security in ECC is based on the elliptic curve discrete logarithm problem, which is computationally harder to solve per bit of key length than the integer factorization problem underlying RSA. As a result, a 256-bit ECC key provides security roughly equivalent to a 3072-bit RSA key. This efficiency advantage translates into practical benefits: faster key generation and cryptographic operations, smaller digital certificates and public keys that reduce bandwidth and processing overhead, lower power consumption that is critical for battery-powered mobile devices and IoT sensors, and faster TLS handshakes that improve application performance. IS auditors evaluate ECC implementations for use of approved elliptic curves (NIST P-256, P-384, and P-521 are widely accepted), key length adequacy relative to the protection period, and whether deprecated curves or non-standard implementations are in use.

Quantum cryptography and post-quantum cryptography are two distinct responses to the threat that quantum computers pose to current cryptographic algorithms. IS auditors must understand both in the context of long-term cryptographic risk planning.

Quantum cryptography uses the principles of quantum mechanics — specifically the quantum property that observation of a quantum state alters it — to distribute cryptographic keys in a way that makes eavesdropping detectable. Quantum key distribution (QKD) provides theoretically information-theoretic security for key exchange. The source manual describes QKD as relying on photon polarization to transmit keys: 'when data is in a quantum state, it becomes impossible for malicious attackers to tamper with it without being detected.' Current QKD implementations are limited by distance (approximately 500 km through guided media) and infrastructure cost.

Post-quantum cryptography refers to classical cryptographic algorithms — such as lattice-based algorithms standardized by NIST in 2024 (CRYSTALS-Kyber for key encapsulation, CRYSTALS-Dilithium for digital signatures) — designed to resist attacks from quantum computers using Shor's algorithm, which can break RSA and ECC by solving their underlying hard mathematical problems efficiently.

The 'harvest now, decrypt later' threat describes the risk that adversaries are collecting encrypted data today with the intention of decrypting it retrospectively when quantum computing matures. IS auditors evaluate whether long-retention encrypted data uses quantum-vulnerable algorithms and whether a post-quantum migration plan exists. For advanced encryption of data in use, see 5.6.7.

Homomorphic encryption is an encryption method that allows mathematical operations — additions and multiplications — to be performed directly on encrypted (ciphertext) data. The result, when decrypted, equals the outcome of those same operations applied to the original plaintext. Unlike standard encryption, which requires data to be decrypted before it can be processed, homomorphic encryption enables computation while data remains encrypted throughout. Key use cases include: supply chain security, where third-party vendors process data without accessing plaintext, limiting the impact of vendor breaches; cloud data security, where organizations keep data encrypted in cloud storage while still enabling search and computation; data security, where users can aggregate values in an unbiased way while keeping individual values private (useful in democratic elections and similar contexts); privacy, where organizations can share private data with customers without affecting privacy; and regulatory compliance, where data is processed outside a regulated jurisdiction in encrypted form and decrypted only within compliant environments. The practical limitations of homomorphic encryption are significant: it introduces computational inefficiency, high storage requirements, reduced performance, and an inability to scale — all arising from the large and complex algorithms required.

A digital signature is a cryptographic mechanism that uses asymmetric key cryptography to simultaneously provide authentication, data integrity verification, and non-repudiation for digital documents and communications. The digital signature process follows four sequential steps. First, a cryptographic hash function (such as SHA-256) is applied to the document, producing a fixed-length message digest that uniquely represents the document's content at the time of signing. Second, the signer encrypts this hash using their private key — the resulting encrypted hash value is the digital signature. Third, the document and its accompanying digital signature are transmitted or stored together. Fourth, the recipient independently hashes the received document using the same hash algorithm, then decrypts the digital signature using the signer's public key to recover the original hash; if the two hash values match, the signature is valid. A valid signature confirms three properties: authentication, because only the holder of the private key could have produced the signature; integrity, because any alteration to the document after signing changes the document's hash and causes signature verification to fail; and non-repudiation, because the signer cannot credibly deny having signed since only they hold the private key. IS auditors evaluate digital signature implementations for algorithm currency (RSA or ECDSA with SHA-256 minimum), private key protection, and the legal and contractual recognition of digital signatures in the applicable jurisdiction.

A digital envelope is an electronic container that protects a message through the use of encryption and data authentication, combining symmetric and asymmetric encryption to capture the strengths of both. The process has three steps. First, the message is encoded using symmetric encryption with a randomly generated secret key — symmetric encryption is fast and efficient for bulk data. Second, the secret key used to encrypt the message is itself encrypted using the recipient's public key (asymmetric encryption) — this securely distributes the key without requiring a pre-shared secret. Third, the recipient uses their private key to decrypt the secret key, then uses that key to decrypt the message. The resulting transmission — the encrypted message combined with the encrypted secret key — is the digital envelope. PGP (Pretty Good Privacy) is a widely known implementation of this model. The technique solves the key-distribution problem inherent in pure symmetric encryption while maintaining encryption performance.

Symmetric and asymmetric cryptographic systems are most powerful when combined. Symmetric encryption is fast but requires both parties to share a secret key in advance — a distribution challenge. Asymmetric encryption solves key distribution using public/private key pairs but is computationally expensive for large data volumes. The combined scheme works as follows: a random symmetric secret key is generated, encrypted using an asymmetric algorithm (so it can be securely transmitted), and then the actual data is encrypted with the symmetric key. This approach provides the speed of symmetric encryption for data and the secure key-distribution properties of asymmetric encryption for key exchange. TLS (Transport Layer Security) is the most widely deployed protocol implementing this model; it secures browser-to-server communication. TLS involves three phases: peer negotiation of cryptographic algorithms, public-key-based key exchange with certificate authentication, and symmetric cipher-based traffic encryption. S/MIME applies the same model to email. Using a fresh symmetric key per session limits the damage from any single key compromise.

Kerberos is a network authentication protocol that uses symmetric encryption and a trusted third-party Key Distribution Center (KDC) to provide single sign-on authentication in distributed computing environments. The KDC consists of two logical components: the Authentication Server (AS), which verifies user credentials and issues Ticket Granting Tickets (TGTs), and the Ticket Granting Server (TGS), which validates TGTs and issues service-specific tickets. The authentication flow has four stages: the user presents credentials to the AS, which issues a TGT encrypted with a session key derived from the user's password; the user presents the TGT to the TGS to request access to a specific service; the TGS issues a service ticket for the requested service; and the user presents the service ticket to the target service to authenticate without re-entering credentials. Kerberos requires tight clock synchronization — the protocol rejects authentication attempts where the clock difference between the client and server exceeds the configured maximum skew, typically five minutes, to prevent replay attacks using expired tickets. IS auditors evaluate Kerberos deployments for NTP synchronization health (skew within five minutes), ticket lifetime policy (shorter lifetimes reduce pass-the-ticket attack windows), KDC redundancy (single KDC is a single point of failure), and KDC security hardening (KDC compromise enables Golden Ticket attacks, where an attacker forges arbitrary valid tickets).

Secure Shell (SSH) is a cryptographic network protocol that provides encrypted, authenticated remote command-line access to systems over an untrusted network. SSH is the primary tool for remote system administration of Linux and Unix servers and network devices, replacing insecure predecessors such as Telnet and rlogin that transmitted credentials in plaintext. IS auditors evaluate SSH configurations across four control dimensions. Authentication methods: SSH supports two primary authentication modes — password-based authentication (knowledge factor, vulnerable to brute-force and credential stuffing) and public key authentication (possession factor, requiring the client to possess the private key corresponding to an authorized public key stored on the server). Key-based authentication is strongly preferred; password authentication should be disabled for administrative accounts. Port and access controls: SSH listens on TCP port 22 by default, a well-known target for automated scanning; changing to a non-standard port and restricting source IP addresses through firewall rules or host-based access controls reduces exposure. Key management: SSH public keys in authorized_keys files must be inventoried, regularly reviewed to remove stale entries, and rotated when personnel change. Logging: all SSH session initiation and termination events, authentication attempts, and commands executed should be logged and integrated into the SIEM for anomaly detection.

The Domain Name System (DNS) resolves human-readable hostnames to IP addresses but was designed without built-in authentication or integrity verification — DNS responses carry no cryptographic proof of origin. This fundamental weakness enables two primary attack types: DNS cache poisoning, in which an attacker inserts forged resource records into a recursive resolver's cache, causing all users served by that resolver to be redirected to attacker-controlled IP addresses; and man-in-the-middle attacks on DNS resolution, in which responses are intercepted and modified in transit. DNS Security Extensions (DNSSEC) address the integrity and authentication weakness by adding cryptographic signatures to DNS resource records. Each DNS zone is signed with the zone owner's private key; the corresponding public key is published in DNSKEY records and validated through a chain of trust anchored at the DNS root. When a resolver receives a DNS response, it verifies the cryptographic signature (RRSIG record) against the published public key; a forged or modified record will fail signature verification and be rejected. DNSSEC provides integrity and authentication only — it does not encrypt DNS queries or responses. DNS over HTTPS (DoH) and DNS over TLS (DoT) provide confidentiality for DNS traffic separately. IS auditors verify DNSSEC enablement on authoritative zones, signature validity, key rollover procedures, and resolver configuration to reject DNSSEC-invalid responses.

Email security encompasses the technical controls that protect the confidentiality, integrity, and authenticity of electronic communications. IS auditors evaluate email security across four control categories. Anti-spoofing controls are DNS-based mechanisms that prevent unauthorized parties from sending email that appears to originate from the organization's domain. SPF (Sender Policy Framework) is a DNS TXT record that lists the IP addresses and mail servers authorized to send email on behalf of the domain; receiving mail servers can reject email from unauthorized sources. DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outbound email created with the organization's private key, allowing receiving servers to verify the signature using the corresponding public key published in DNS. DMARC (Domain-based Message Authentication, Reporting and Conformance) builds on SPF and DKIM by publishing a policy record that instructs receiving servers how to handle email that fails SPF or DKIM checks — options include none (monitor only), quarantine, or reject — and enables aggregate reporting on authentication failures. Email encryption uses SMTP over TLS for transport-level encryption of email in transit and S/MIME or PGP for end-to-end content encryption that persists after delivery. Anti-spam and anti-phishing filters use reputation databases, machine learning models, and URL scanning to identify and quarantine malicious email before delivery. Content filtering scans email attachments and embedded links for malware and phishing content. IS auditors verify the existence and correct configuration of all three anti-spoofing records, TLS enforcement on SMTP connections, and the effectiveness of anti-phishing filtering controls.

An IS auditor evaluates encryption controls through a structured four-stage process. The first stage is policy and standards review: the auditor examines the organization's cryptographic policy and technical standards document to confirm that approved algorithms are specified, key length requirements are defined, key lifecycle procedures are described, and an exception approval process exists; the absence of a formal cryptographic policy is a material control gap. The second stage is algorithm and key length assessment: the auditor inventories all encryption implementations across the organization — data at rest, data in transit, application-layer encryption — and verifies that algorithms in use are current approved standards and that key lengths meet current recommendations; any use of deprecated algorithms (DES, RC4, MD5, SHA-1) or key lengths below current minimums represents a finding requiring remediation. The third stage is key management evaluation: the auditor assesses the complete key lifecycle — key generation from cryptographically secure random sources, key storage protection (hardware security module or approved key vault; plaintext storage is a critical finding), key rotation schedule adherence, and secure key destruction procedures. The fourth stage is implementation testing: the auditor samples sensitive data repositories, backup media, and data transmission paths to verify that encryption is actually applied as required by policy; an encryption policy that exists on paper but is not enforced in practice is the most frequent encryption audit finding.

Public key infrastructure (PKI) is a comprehensive system for creating, distributing, managing, and revoking digital certificates that bind public keys to verified identities. PKI solves the fundamental problem of public key authenticity: without PKI, a party receiving a public key has no reliable way to confirm that the key actually belongs to the claimed entity rather than an impersonator. A PKI consists of policies, procedures, hardware, software, and personnel organized around a hierarchical trust model. At the apex of the hierarchy is the Root Certificate Authority (CA), which issues certificates to one or more Intermediate CAs; the Root CA is typically kept offline in a hardware security module to protect its private key. Intermediate CAs issue end-entity certificates to users, servers, devices, and code-signing identities. Trust is established through a certificate chain: a certificate is valid and trustworthy if a continuous chain of valid signatures can be traced from the end-entity certificate through one or more Intermediate CAs to a Root CA that is present in the trusting system's trusted root store. IS auditors evaluate PKI for CA hierarchy design and security, certificate issuance policies (Certificate Policy and Certification Practice Statement documents), revocation mechanisms (CRL, OCSP), root CA protection, and certificate lifecycle management.

A digital certificate is a structured electronic document issued by a Certificate Authority (CA) that binds a public key to a verified identity using the CA's digital signature. Digital certificates follow the X.509 standard and contain four primary components. The Subject field identifies the entity to which the certificate was issued — for TLS server certificates, this is typically the domain name; for client and personal certificates, it identifies the individual or device. The Public Key field contains the public key that the certificate certifies as belonging to the subject — the CA has verified this ownership as part of the certificate issuance process. The CA Digital Signature is the CA's cryptographic signature over the certificate content, providing evidence that the certificate was issued by the named CA and has not been altered since issuance. The Validity Period specifies the dates between which the certificate is considered valid — a 'not before' date and a 'not after' (expiration) date. IS auditors evaluate certificate lifecycle management across four areas: certificate inventory completeness (all deployed certificates known and documented), expiration monitoring (automated alerting before expiration, with renewal workflows), revocation procedures (CRL or OCSP checking enabled for relying party systems), and private key protection (keys stored in HSM or protected storage, with documented access controls).

Key management covers the full lifecycle of a cryptographic key from birth to destruction. Creation (generation) produces the key using an approved key generator. Distribution transfers it to the intended recipient over a secured channel. Storage and custody protects it — typically in a hardware or software certificate store — with dual custody or split knowledge requiring two or more people for high-value keys. Rotation retires old keys before they are lost or compromised, and replaces them with fresh ones. Recovery and backup, often through key escrow, ensures that encrypted data can still be accessed if a key fails. Destruction formally ends a key's life through suspension, revocation, expiry, or erasure. An IS auditor should verify each stage is governed by documented policy and that evidence of compliance exists.

Certificate revocation is the process of permanently invalidating a digital certificate before its scheduled expiration date, making it untrusted to all relying parties from the moment of revocation. Revocation is necessary when a certificate's private key has been compromised — because an attacker possessing the private key can impersonate the certificate's subject regardless of whether the certificate has expired. Other revocation reasons include change in the certificate subject's information, departure of the individual named in the certificate, or compromise of the issuing CA. Two mechanisms communicate revocation status to relying parties. The Certificate Revocation List (CRL) is a signed list of revoked certificate serial numbers published periodically by the issuing CA; relying parties download and cache the CRL and check it against presented certificates. CRL disadvantages include the potential for large download sizes and the latency between revocation and CRL publication, during which a recently revoked certificate may still appear valid to systems using a cached CRL. The Online Certificate Status Protocol (OCSP) allows relying parties to query an OCSP responder in real time with a specific certificate serial number, receiving an immediate signed response of 'good,' 'revoked,' or 'unknown.' OCSP stapling is an optimization in which the server pre-fetches its OCSP response and delivers it to clients during the TLS handshake, reducing OCSP query latency. IS auditors verify that revocation mechanisms are operational, that relying party systems are configured to perform revocation checks, and that revocation is initiated promptly when private key compromise is suspected.

A Certificate Revocation List (CRL) is a CA-published blacklist of digital certificates revoked before their scheduled expiry. Browsers and applications retrieve the current CRL from a CRL Distribution Point (CDP) hosted on an LDAP or web server. CRLs are published periodically, which creates a trust gap between publications. Two revocation states exist: revoked (irreversible — triggered by private key compromise, improper issuance, or policy non-compliance) and hold (reversible — used when the private key's status is temporarily uncertain). OCSP (Online Certificate Status Protocol) addresses the latency problem by allowing real-time per-certificate status queries to the CA's responder. OCSP stapling enhances this further: the web server caches the CA's signed OCSP response and staples it to the certificate, removing the browser's need to contact the CA directly, improving performance and user privacy.

PKI infrastructure introduces distinct risk categories that IS auditors must systematically evaluate. Outdated protocol risk arises when the CA servers, client systems, and PKI infrastructure use deprecated cryptographic algorithms (SHA-1, MD5) or deprecated protocol versions (TLS 1.0, TLS 1.1) that are vulnerable to known attacks; the auditor verifies that only current algorithms and protocol versions are configured. Weak key storage risk is one of the most critical PKI risks: the Root CA's private key must be stored in an offline, air-gapped hardware security module (HSM), because a compromised root CA key invalidates the trustworthiness of every certificate the CA has ever issued; intermediate CA keys require HSM storage at minimum; online storage of CA private keys represents a critical finding. Inadequate revocation risk occurs when CRL publication frequency is too low or OCSP infrastructure is unreliable, creating extended windows during which compromised certificates remain trusted; the auditor verifies revocation publication frequency and OCSP availability. CA compromise risk encompasses the governance controls that protect CA operations: multi-person authorization requirements for certificate issuance, physical security of CA hardware, audit logging of all CA operations and administrative actions, and business continuity planning for CA services. IS auditors combine document review with technical testing to evaluate all four risk categories.

IS auditors apply specific procedures when evaluating PKI implementations, collecting evidence across four primary audit areas. Certificate inventory procedures involve obtaining a complete export of all certificates issued by the organization's CAs, verifying that the inventory is current and reconciled against deployed certificates, checking for expired certificates in active service, and confirming that certificate issuance procedures follow the published Certificate Policy. Revocation verification procedures involve downloading and inspecting the most recently published CRL for its publication date and currency, testing OCSP responses for a sample of active certificates to verify real-time accuracy, and confirming that relying party systems (web servers, application clients, email gateways) are configured to perform revocation checks on certificates they receive. Key management audit procedures involve reviewing hardware security module access logs, key ceremony documentation (especially for Root CA key generation), key rotation schedule compliance, and evidence of dual-control or split-knowledge requirements for high-value CA key operations. CA policy review involves examining the Certificate Policy (CP) document — which defines the types of certificates the CA issues and the standards they meet — and the Certification Practice Statement (CPS) — which defines the specific operational procedures the CA follows to implement the CP. Significant discrepancies between the CP/CPS and actual CA operations are reportable findings. IS auditors should also assess whether the CA has undergone an independent audit (such as WebTrust for CAs) and review the audit opinion and any findings.

Virtualization and cloud-based infrastructure have fundamentally changed the risk profile of IS environments, introducing new attack surfaces and governance challenges that IS auditors must evaluate. Virtualization risks center on the hypervisor — the software layer that manages multiple virtual machines (VMs) on a single physical host. A hypervisor vulnerability or compromise can expose all hosted VMs simultaneously. VM escape attacks, where malicious code in one VM breaks out of its containment to affect other VMs or the hypervisor itself, represent a critical threat. VM sprawl — the unchecked proliferation of virtual machines that may not be tracked, patched, or actively managed — creates an expanding attack surface of unmanaged endpoints. Virtual network traffic between VMs on the same physical host may bypass physical network security devices such as firewalls and IDS. Cloud-specific risks differ in character: shared multi-tenant infrastructure requires strong isolation guarantees from the cloud service provider; reduced organizational visibility into the provider-managed infrastructure layers limits the ability to independently verify security controls; the shared responsibility model creates governance gaps when the allocation of security responsibilities between provider and customer is misunderstood; and data residency uncertainty may create regulatory compliance issues if data is stored in geographic regions with different legal frameworks. IS auditors evaluate both virtualization and cloud environments, recognizing which layers are within the organization's direct control and which require contractual or third-party assurance from the provider.

Virtualization is a technology that enables multiple independent operating system instances — called guest virtual machines (VMs) — to run simultaneously on a single physical host by interposing a hypervisor between the physical hardware and the guest operating systems. The virtualization architecture comprises three layers: the physical host, which provides the actual computing resources; the hypervisor, which allocates physical resources (CPU cycles, memory, storage, network interfaces) to each guest VM and enforces isolation between them; and the guest VMs, each running its own operating system and applications as though they were on dedicated physical hardware. Two types of hypervisor exist: Type 1 (bare metal) hypervisors run directly on physical hardware and are used in production data centers; Type 2 (hosted) hypervisors run on top of a conventional operating system and are typically used for desktop virtualization. The hypervisor is the most security-critical component in the virtual environment: because it controls the allocation and isolation of all resources for all guest VMs, a vulnerability in or compromise of the hypervisor simultaneously exposes every VM hosted on that physical system. Virtual machines on the same physical host communicate through virtual network switches that may bypass physical network inspection devices, creating an intra-host network traffic blind spot. IS auditors evaluate hypervisor patch currency, VM inventory and lifecycle management, guest OS isolation configuration, and controls for intra-host virtual network traffic.

A virtual circuit is a logical communication pathway created over a packet-switched network that provides the endpoints with the functional appearance of a dedicated point-to-point connection. Virtual circuits are categorized into two types based on their establishment and persistence. A permanent virtual circuit (PVC) is a pre-established, always-available logical connection configured by the network provider between two fixed endpoints. The PVC remains continuously active regardless of whether data is currently being transmitted, providing guaranteed bandwidth and deterministic latency characteristics. PVCs are well-suited for high-volume, consistent traffic between fixed locations such as a headquarters-to-disaster-recovery-site WAN link. Because the path is established by the provider during provisioning rather than dynamically negotiated during use, PVCs have reduced exposure to route manipulation attacks. A switched virtual circuit (SVC) is established on demand when a session is initiated and torn down when the session ends — functioning analogously to a traditional telephone call. SVCs are appropriate for variable or intermittent connectivity requirements between multiple endpoints. SVCs require dynamic call setup and teardown signaling, introducing authentication and authorization considerations for the setup protocol. IS auditors evaluate whether PVCs provide the bandwidth capacity required for business continuity objectives, whether SVC authentication mechanisms are appropriately configured, and whether virtual circuit configurations are documented and reviewed periodically.

A VLAN (Virtual Local Area Network) is a logical partition of a physical network switch that groups switch ports into isolated broadcast domains, enabling network segmentation without changes to physical cabling or hardware topology. VLANs are created and enforced by network switches and provide the primary mechanism for Layer 2 network segmentation in enterprise environments. IS auditors evaluate VLAN implementations across three dimensions. VLAN segmentation examines whether VLANs are defined and configured in alignment with the organization's network segmentation policy — verifying that sensitive network zones (such as core banking, management, and user workstations) are in separate VLANs with appropriate inter-VLAN access controls. VLAN security risks include two specific attack vectors: VLAN hopping, in which an attacker connected to an access port exploits switch trunk negotiation protocols (such as DTP) or uses double-tagged Ethernet frames to inject traffic into VLANs they should not be able to reach — mitigated by disabling trunk negotiation on all access ports and explicitly configuring trunk ports; and native VLAN attacks, in which untagged traffic on a trunk port is associated with the native VLAN, which if left at the default (VLAN 1) may overlap with sensitive management traffic — mitigated by reassigning the native VLAN to an unused, non-routable VLAN. IS auditor controls evaluation verifies that switch configuration files show access ports with DTP disabled, trunk ports explicitly configured, and native VLAN set to a non-default, non-routable value.

A virtual storage area network (VSAN) is a logical partition within a physical SAN fabric that creates isolated storage domains — separate virtual storage networks within the same physical infrastructure. VSANs allow multiple functional groups, applications, or security zones to share physical SAN hardware while maintaining logical separation of their storage traffic and access. IS auditors evaluate VSANs across three security dimensions. Storage isolation verifies that production, test, development, and backup storage domains are placed in separate VSANs, preventing workload cross-access — a test job that can access production storage volumes represents a critical data integrity risk. Traffic segmentation ensures that storage I/O traffic from different VSANs is logically separated on shared physical links, reducing the risk of data leakage through shared SAN paths. Access control through SAN zoning defines which host bus adapters (HBAs) on which servers are authorized to communicate with which storage targets within each VSAN, ensuring that only approved hosts can access specific storage volumes. IS auditors review VSAN zone configurations against an approved host-to-storage access matrix, verify that production VSANs are not accessible from development or test hosts, and confirm that SAN zone changes are subject to change management controls.

Software-defined networking (SDN) is an approach to network architecture that separates the control plane — which makes routing and forwarding decisions — from the data plane — which actually forwards packets based on those decisions. In traditional networks, the control and data planes reside together on each physical network device, requiring device-by-device configuration that creates operational complexity and vendor lock-in. In an SDN architecture, a centralized SDN controller manages all forwarding decisions for the network and communicates those decisions to data plane devices (switches and routers) using standardized protocols such as OpenFlow. This centralization enables consistent, programmable network-wide policy deployment, faster implementation of network changes, and hardware abstraction from the control logic. The primary security implication of SDN is the centralization risk introduced by the SDN controller: because the controller makes all forwarding decisions for the entire network, an attacker who compromises or disrupts the controller can simultaneously control or disrupt the forwarding behavior of all managed network devices. IS auditors evaluate SDN deployments for controller security hardening, authentication and encryption of control plane communications between the controller and data plane devices, isolation of the SDN management plane from production traffic, high availability configuration for controller redundancy, and access control and audit logging for the SDN management interface.

Containerization is a form of operating system-level virtualization that enables multiple isolated application instances — called containers — to run on a single host operating system while sharing the same OS kernel. Unlike full virtual machines, which each include a complete guest operating system isolated by a hypervisor, containers are lightweight processes that share the host's kernel and system libraries, providing faster startup times and lower resource overhead. Container isolation is enforced at the process and namespace level using Linux kernel features such as namespaces and cgroups. The security implications of this shared-kernel architecture differ from traditional VM security. Container escape risk: because containers share the host OS kernel, a kernel vulnerability exploited by code in one container could allow that code to affect other containers on the same host or the host OS itself — a more impactful risk than a guest OS vulnerability in a VM environment. Container image security: containers are deployed from images that may include outdated or vulnerable software packages from public registries; unscanned images introduce known vulnerabilities into the container environment. Privileged container risk: containers configured to run in privileged mode have elevated access to host OS resources, significantly reducing the isolation benefit. Container orchestration security: Kubernetes API server access, RBAC policies, and network policies between pods require dedicated security configuration. IS auditors evaluate container image scanning processes, privileged container policies, Kubernetes RBAC configuration, and network policy controls between container workloads.

Cloud migration is the transfer of an organisation's data and applications to a cloud infrastructure. It takes three forms: on-premises to cloud, cloud-to-cloud (moving between providers), and reverse cloud migration (returning to on-premises or another model). Security risks specific to migration include multi-tenancy (shared infrastructure with unknown co-tenants), API vulnerabilities (unsecured communication channels during transfer), compliance risk (data governance, ownership, and regulatory requirements may be harder to enforce in the cloud), uncontrolled growth (post-migration addition of new cloud services without security review), data loss (technical failures or human error during transfer), data security (encryption in transit, at rest, and in process), legacy architecture incompatibility, and reduced visibility (the organisation loses direct oversight of infrastructure managed by the CSP). Additional risk categories in the source include data remanence (residual data remaining on decommissioned infrastructure) and talent gap (lack of cloud security expertise). An IS auditor evaluating a migration plan should verify that controls address the full range of migration risk categories before data moves.

The shared responsibility model (SRM) is a framework that defines the division of security responsibilities between a cloud service provider (CSP) and its customers. The division of responsibility varies based on the cloud service model selected. Under Infrastructure as a Service (IaaS), the CSP is responsible for securing the underlying physical infrastructure, network, and hypervisor — collectively described as 'security of the cloud.' The customer is responsible for securing the operating system, middleware, application code, data, and access management controls — collectively described as 'security in the cloud.' Under Platform as a Service (PaaS), the CSP additionally takes responsibility for the operating system and runtime environment; the customer retains responsibility for application code, data, and access management. Under Software as a Service (SaaS), the CSP manages virtually the entire stack; the customer retains responsibility for user access management, data configuration, and data governance. The most frequent organizational failure is misunderstanding the model — assuming that the CSP manages security controls that are actually the customer's responsibility, creating unaddressed security gaps. IS auditors review the organization's cloud responsibility matrix against the CSP's official shared responsibility documentation, identify controls that fall within the customer's domain, and verify that those controls are implemented and operating effectively. DevSecOps integration into the cloud pipeline is a related control that IS auditors evaluate for cloud-native security.

The Cloud Security Alliance (CSA) identifies eleven major cloud security threats. Identity and access management deficiencies are particularly targeted because identity is the primary access mechanism in cloud environments. Insecure APIs create pathways for unauthorised access between applications. Misconfiguration and inadequate change control are operationally common because CSPs provision resources in minutes, causing errors to propagate quickly. Lack of cloud security architecture — including Security Reference Models (SRM), the Principle of Least Privilege (POLP), and isolation zones — leaves environments structurally exposed. Insecure software development risks arise from inadequately protected developer endpoints. Third-party supply chain vulnerabilities are pervasive. System vulnerabilities require continuous scanning. Accidental data disclosure typically results from misconfigured sharing settings, mitigated through DLP. Container and serverless misconfiguration creates exploitable security holes. Organised crime and APTs target cloud configurations. Data exfiltration from cloud storage requires proactive detection and prevention.

DevSecOps is the convergence of development, security, and operations teams into a unified discipline with shared responsibility for security outcomes. Traditional practice added security reviews after development completed — a model incompatible with agile releases and cloud-native microservices. DevSecOps integrates security as an automated, continuous component of CI/CD pipelines from the first line of code. The key principle — shifting security left — means security controls appear at the beginning of the SDLC, not the end. Core benefits include: faster, cost-effective, and secure delivery — eliminating repeated processes at the end of the delivery cycle reduces rework cycles, and less staff are required, leading to an overall reduction in employment costs; proactive security issue resolution before vulnerabilities propagate; faster vulnerability patching embedded in the pipeline; automation of security test suites; simplified compliance reporting through automated scans; and standardised security posture across all development stages. For an IS auditor, the primary question is whether security scanning and review are genuinely embedded in the pipeline, or remain a manual post-development gate.

Mobile, wireless, and IoT devices are grouped together in this cluster because they share a fundamental security characteristic: they operate outside the physical and network perimeter that traditional enterprise security controls assume. Portable and wireless devices present a ubiquitous threat to an enterprise's information assets and must be properly controlled — because such devices operate in environments where physical controls are lacking or nonexistent.

The three sub-domains of this cluster each represent a different dimension of this shared problem:

Mobile devices (5.9.1–5.9.8) are corporate assets that travel with employees, extending the enterprise data boundary to airports, hotels, and public spaces where physical and network controls are absent.

Wireless networks (5.9.9) extend corporate network connectivity through a medium — radio frequency transmission — that any nearby device can intercept, requiring compensating controls at the protocol and authentication layer.

IoT devices (5.9.10) embed computing capability into physical infrastructure — HVAC, badge readers, printers — where security was not a design priority and patching may be impractical.

Each sub-domain has its own specific threats, controls, and audit procedures, covered in the sections that follow. The IS auditor's role across the entire cluster is to answer: what compensating controls substitute for the absent perimeter, and are they in place and effective?

Mobile computing encompasses the use of portable devices — smartphones, tablets, laptops, and USB storage media — that are transported outside the controlled corporate environment during normal use, extending the organizational network perimeter to wherever these devices travel. This mobility creates four primary categories of security risk that form the foundation for all mobile security evaluation in sections 5.9.2 through 5.9.7.

Device loss or theft: mobile devices are frequently lost or stolen due to their portability. When a device leaves the corporate premises, the physical security controls of the office — access cards, CCTV, locked doors — no longer protect it. Data on the device may be lost or accessible to unauthorized parties.

Malware propagation: mobility provides users with the opportunity to leave enterprise boundaries and thereby eliminates many security controls. Mobile devices cross perimeters and connect to untrusted wireless networks and app stores, carrying malware back into the enterprise network when they reconnect.

Unauthorized access: if no authentication requirements are applied to the device, anyone who possesses a lost or stolen device can access it and all its data. Outside the office environment, there are no colleagues or physical controls to notice the breach.

Data exposure: mobile devices store corporate data locally in email caches, downloaded documents, and application storage. If the enterprise is not managing the device, there is no visibility into what data is stored, how it is protected, or whether it has been accessed by unauthorized parties.

The specific threats that exploit these four risk categories are catalogued in 5.9.2. The controls that address each category are detailed in 5.9.3. Mobile Device Management (MDM) as the enforcement mechanism is the subject of 5.9.4.

Building on the four mobile risk categories established in 5.9.1 — loss/theft, malware propagation, unauthorized access, and data exposure — this section catalogs the specific threats that exploit those risks. The SOMA mnemonic organises the four primary mobile device threat categories that IS auditors must evaluate.

Stolen and lost devices: the CISA source identifies both lost business and data leakage as distinct threat outcomes — lost devices mean employees cannot work, and data on devices that are not backed up is permanently lost. The auditor evaluates the gap between loss report and remote wipe execution, encryption enforcement, and backup procedures.

OS vulnerabilities: the OS may contain vulnerabilities that allow access to the device, including through drive-by downloads — malware installed without user knowledge by visiting suspicious websites or opening malicious links. Devices that are jailbroken (restrictions intentionally removed) are particularly vulnerable because the apps may not come from secure sources. The IS auditor evaluates MDM-enforced OS version compliance and quarantine status of non-compliant devices.

Malicious applications: applications may carry malware that propagates Trojans or viruses, or transform the device into a gateway for malicious outsiders entering the enterprise network. Open public Wi-Fi networks are also an attack vector — they typically do not require passwords or use encryption, making it easier to spy on device activity and deliver malicious content. The IS auditor evaluates MDM app allow-listing and prohibition of sideloading.

Aged/outdated software: mobile devices that are outdated may not receive security updates from device manufacturers. Identity theft and information interception are downstream outcomes when devices run software with known unpatched vulnerabilities. The IS auditor reviews patch timeliness metrics and MDM update-enforcement policies.

The controls that address each SOMA category one-for-one are the subject of 5.9.3.

Building on the SOMA threat catalog from 5.9.2, this section identifies the DERWA controls that address each threat category. Controls are available to reduce the risk of disclosure of sensitive data stored on mobile devices; many of these controls can be enforced by Mobile Device Management (MDM) systems and/or secure containers.

Device registration (D): all mobile devices authorized for business use should be registered in a database — devices that are personally owned should be flagged. Organizations can push updates or manage authorized devices and exclude unregistered devices from corporate access. Registration is the prerequisite for all other controls.

Encryption (E): only content that is absolutely needed should be stored on the device; data that is stored should be backed up regularly, and full-device encryption ensures that a lost or stolen device's data is unreadable without the correct passcode. It also may be necessary to classify some data as inappropriate for storage on a mobile device.

Remote wipe (R): a remote wipe feature deletes all data from the mobile device over the mobile phone service or the internet. Note: remote wipe does not permanently remove data — data may still be recoverable. Encryption is the primary data-at-rest protection; remote wipe is the secondary response after loss.

App controls (A): only applications from official application stores should be authorized. Applications not in use should be closed. Virus detection and antivirus software should be updated on mobile devices to prevent malware propagation. App allow-listing and prohibition of sideloading address the SOMA M (Malicious app) category.

Wireless/network policy (W): mobile device owners should not connect to public Wi-Fi; all unused Wi-Fi networks should be deleted; Bluetooth should be disabled when not in use; mobile devices should connect to the enterprise network via VPN. These controls address both the SOMA S (interception of lost-device traffic) and SOMA M (malware delivery via open Wi-Fi) categories.

How MDM operationalizes these five controls across an entire device fleet — enforcement rates, compliance monitoring, and response capability — is the subject of 5.9.4.

Where 5.9.3 identifies the DERWA controls that mobile devices should have, Mobile Device Management (MDM) is the centralized technology suite that operationalizes those controls across an enterprise device fleet. MDM is a collective suite of tools and technologies used to secure and manage mobile devices, applications, data, and access — its objectives are to improve security, provide monitoring, enable remote management, and support troubleshooting of mobile devices.

Enrollment is the prerequisite: devices must be enrolled before any MDM capability reaches them. The enrollment process should not be so complicated that it discourages users. Organizations should ensure that the enrollment process is simple and that all devices are enrolled. For BYOD, enrollment as a condition of corporate access is the governance mechanism — see 5.9.5.

Policy enforcement involves remote deployment of the DERWA security configurations: encryption, passcode requirements, app allow-listing, VPN profiles, and network restrictions. MDM should be able to remove undesirable applications, manage data, and enforce configuration settings across carrier networks and Wi-Fi connections. Policies in 'pending' state are not protecting the device.

Compliance monitoring involves the continuous reporting of device compliance against deployed policies. Best practices require that MDM features — such as push configuration changes, patches, and software — are updated and available to users. The IS auditor evaluates whether compliance reports are reviewed on a defined cadence and whether non-compliant devices are remediated within a defined SLA. End-user self-service capabilities — remote data wipe, password reset, and lost device tracking — support compliance culture.

Remote response includes remote lock, remote wipe, and application deployment/removal. The CISA source notes explicitly that remote wipe does not permanently remove data — data may still be present and recoverable. This means encryption (5.9.3-E) remains the primary data-at-rest protection; remote wipe is the secondary response after confirmed loss.

IS auditors evaluate MDM enrollment completeness, policy enforcement rates, compliance report review evidence, and remediation SLA adherence. Audit procedures for mobile devices — including MDM configuration testing — are detailed in 5.9.7.

Bring Your Own Device (BYOD) is an organizational policy that permits employees to use personal mobile devices to access corporate networks, applications, and data. BYOD introduces a governance problem distinct from corporate-owned device management: the organization must apply the DERWA controls from 5.9.3 and the MDM program from 5.9.4 to a device it does not own. Risk related to BYOD is similar to mobile computing risk — but each control from 5.9.3 is complicated by the ownership boundary.

BYOD policy: unlike corporate devices where security requirements are set by IT policy, BYOD requires a formal management-approved agreement before any control can be enforced. An acceptable use agreement (AUA) should be required before use of a personal device is permitted for business purposes. The agreement may state that devices can be seized, if necessary, for legal matters. BYOD should be approved by executive management and be subject to oversight and monitoring. Without policy, the organization has no contractual basis for the technical controls.

Data separation: the 5.9.3 containerization control separates corporate from personal data. On BYOD, this separation must be technically enforced and verified — when a personal device is used for business tasks, there is commingling of personal data. Business data ownership becomes complicated: if a device is lost or stolen, the company may trigger a remote wipe that also destroys personal information. The commingling problem — corporate email in personal iCloud — represents a failure of the data separation control.

MDM as a condition of access: the 5.9.4 enrollment requirement applies to BYOD but with a governance mechanism: MDM enrollment must be a condition of corporate access, not an optional recommendation. Responsibility for maintaining security when using personal devices is shared between the user and the IT department — but the IT department's side of that agreement requires enrollment. Employees who do not accept MDM may not access corporate resources.

Risk acceptance and exit strategy: management must formally accept the residual risk of BYOD (reduced control compared to corporate-owned devices). An exit BYOD strategy must specify procedures to be followed when employees who use their own devices leave the organization — failure to enforce this may lead to backdoor attacks from disgruntled former employees.

IS auditors evaluate BYOD programs by checking: formal policy existence and currency; data separation enforcement (tested, not assumed); MDM enrollment as a mandatory condition; and formal management risk acceptance.

Building on the SOMA threat catalog from 5.9.2, this section identifies the seven general security exposures that arise specifically from how mobile devices access the internet. Smartphones and other mobile devices access the internet by connecting to WLANs or over mobile networks. Most devices use 4G — an IP packet-switched network that offers video conferencing, HD streaming, VoIP, and mobile TV — with 5G adoption increasing for enhanced coverage, low latency, and ultra-high speed data rates.

The seven general exposures associated with wireless and mobile access are:

1. Interception of sensitive information: information is transmitted through the air, which increases the potential for unprotected information to be intercepted by unauthorized individuals. This is the network-layer manifestation of the SOMA malicious-app and stolen-device risks.

2. Loss or theft of devices: devices tend to be relatively small, making them much easier to steal or lose — the physical form-factor risk amplified by the mobile use context.

3. Data loss from device: theft or loss can result in the loss of data stored on the device — potentially several gigabytes. If encryption is weak or not applied, an attacker may access the information because it may only be protected by a password or PIN. (Encryption and remote wipe controls addressing this are established in 5.9.3.)

4. Misuse of devices: devices can be used to gather or intercept information being passed over wireless networks for financial or personal benefit.

5. Weak wireless network authentication: the protocols that govern how a mobile device proves its identity to a Wi-Fi or cellular network before traffic is permitted are not sufficiently strong. This is an infrastructure-layer exposure — the handshake between device and network. Gaps here enable rogue access point attacks (the device connects to an attacker's AP instead of the legitimate one) and session hijacking, because the device cannot verify the network's identity.

6. Weak device-level authentication controls: the mechanisms that govern who may unlock and operate the mobile device — PINs, passwords, biometrics — are not sufficiently strong or consistently enforced. This is a user-access-layer exposure — the barrier between a person and the device's data. It is distinct from exposure 5: even when a device successfully authenticates to a legitimate network (closing exposure 5), it may still be operated by an unauthorized person if device-level controls are weak or absent.

7. Weak file security: wireless phones and tablets do not use the type of file access security that other computer platforms provide. Mobile platforms historically rely on app-sandboxing — each app is confined to its own data sandbox and cannot directly read another app's files — rather than OS-level file ACLs (such as POSIX permissions on Linux or NTFS access control lists on Windows). This means there is no central, auditable file-access log comparable to what traditional platforms provide: a malicious or compromised app inside one sandbox cannot directly exfiltrate another app's files, but the organization also loses the visibility that OS-level access control auditing provides. This is a mobile-platform-specific characteristic — not a general IT risk — and is distinct from the loss/theft or interception risks above.

For wireless network-side controls (WPA3, rogue AP detection, guest isolation) that address exposures 1 and 4 from the network infrastructure perspective, see 5.9.9.

IS auditors evaluate mobile device security programs by verifying that the DERWA controls from 5.9.3 are in place and that the MDM program from 5.9.4 is operationally effective. Mobile devices should be subject to regular audits to ensure that vulnerabilities and threats are addressed before they propagate. The source states that audit procedures for mobile devices are the same procedures the IS auditor would undertake in a BYOD audit.

Stage 1 — Scope and Inventory (auditing the D in DERWA: Device Registration): the auditor obtains the MDM system enrollment report and compares it against HR employee records, contractor lists, and network access logs to identify the complete population of mobile devices accessing corporate resources. The gap between MDM enrollment and total access population represents devices entirely outside the 5.9.3 control scope. Scope always precedes configuration testing — you cannot audit coverage you have not measured.

Stage 2 — Policy Review (auditing the governance foundation): the auditor verifies that a security policy exists for mobile devices, that it addresses mobile device use and specifies the types of information and devices permitted, that the BYOD policy (5.9.5) is current and management-approved, and that the MDM configuration policy reflects the 5.9.3 control requirements.

Stage 3 — MDM Configuration Testing (auditing the 5.9.4 policy enforcement function): the auditor directly reviews the MDM console to verify: device software and antivirus are current (SOMA-A and SOMA-O from 5.9.2); Bluetooth is disabled when not in use (5.9.3-W); mobile OS is appropriately patched; remote wiping/locking is enabled and tested; there are no unmanaged devices on the network; cameras are covered and location services disabled when not required. The sensitive data encryption control (5.9.3-E) is verified here — sensitive data must be properly secured at rest and in transit via TLS/VPN.

Stage 4 — Compliance Evidence (auditing the 5.9.4 monitoring function): the auditor determines whether asset management processes track and monitor mobile devices; evaluates whether security monitoring and log reviews are in place; verifies rules for downloading software; evaluates effective change management processes for mobile devices; and evaluates DR/BC processes to restore mobile devices in case of disaster, including whether the DR/BC plan is tested regularly.

Awareness training: the auditor verifies that users are trained not to open unknown links and attachments, and that the training specifies what information may be stored on mobile devices.

Mobile payment systems enable financial transactions through mobile devices using Near Field Communication (NFC), QR codes, and in-app payment interfaces. Mobile payment systems can be linked to other payment infrastructure such as credit cards and bank accounts. Types include digital wallets (e-wallets storing payment and PII), mobile wallets (replacing physical cards — e.g., Apple Pay, Samsung Pay), digital currency wallets (cryptowallets), and contactless payment communication technologies using embedded chips in devices.

Tokenization is the core security mechanism: the customer's real PAN is replaced by a payment token — a randomly generated surrogate that is bound to a specific device and may be limited to a specific transaction, time window, or number of uses. Intercepted tokens cannot be used to make unauthorized purchases or derive the real PAN. A CISA-identified threat specific to tokenization is token data compromise: this is more prevalent where issuers seek to leverage the tokenization service from the payment networks but implement their own token service instead, leading to increased risk if that token data is compromised. IS auditors verify that tokenization is handled by the card network or issuing bank.

NFC security characteristics: the short operating range (~4cm) requires physical proximity for both legitimate transactions and interception attempts. Payment credentials are stored in the secure element — hardware-protected storage on the device. NFC communications are encrypted between device and payment terminal.

Mobile payment threats — building on the SOMA threat catalog from 5.9.2 — include phishing (mobile phones mix business and social media, enabling sophisticated social engineering), mobile malware (installed via social engineering or insecure Wi-Fi man-in-the-middle), spoofing (fake access points or websites to collect customer data), unauthorized access (attacker possessing a lost or stolen device bypasses PIN/fingerprint lock), tampering (backdoor in a modified payment application to capture login details), application vulnerabilities (weak authentication enabling unauthorized access), payment fraud (exploiting weaknesses in registration to add a second device), token data compromise, and identity theft.

Fraud controls include real-time transaction monitoring, velocity checks detecting rapid small transactions, device-binding controls invalidating tokens on unauthorized devices, and geographic anomaly detection. Mobile payment systems are subject to PCI-DSS requirements, which the IS auditor should verify.

Wireless technologies enable devices to communicate without physical connections using radio frequency transmissions or electromagnetic signals through free space. This includes complex systems — wireless wide area networks (WWANs), WLANs, and cellular networks — and simpler devices such as Bluetooth headphones and infrared controls. Wireless networks serve as the transport mechanism between devices and between devices and traditional wired networks.

Wireless networks are categorized into four coverage-based groups: WWANs (cellular, satellite), WLANs (802.11 Wi-Fi), Wireless personal area networks (WPANs, including Bluetooth), and wireless ad hoc networks. IS auditors evaluate WLAN security across four control dimensions.

Encryption standards and authentication: WPA3 is the newest wireless security generation, delivering robust authentication and increased cryptographic strength — suitable for highly sensitive communications. WPA2 (ratified 2004) implemented AES for higher security but contains a vulnerability allowing attackers to obtain keys to attack devices on the same network. WPA-Enterprise and WPA2-Enterprise use a RADIUS server to provide security for wireless networks in business environments. WEP (Wired Equivalent Privacy) has multiple known flaws and does not offer strong enough security for enterprise applications — its use represents a critical audit finding. WPA2-PSK uses a shared pre-shared key, meaning all users share the same key; WPA2/WPA3-Enterprise authenticates each user individually.

SSID management: broadcasting the corporate SSID name enables attacker identification of the target network. Suppression provides minor benefit; WPA3 or WPA2-Enterprise is the substantive control.

Rogue access point detection: unauthorized APs may be deployed without proper security, enabling credential capture or traffic interception. Wireless intrusion prevention systems (WIPS) and regular RF spectrum scanning detect and locate rogue APs.

Guest network isolation: guest wireless networks must be on a separate VLAN that cannot route traffic to the corporate network. A guest VLAN on the same segment as corporate users is a network architecture failure that grants any guest device access to corporate systems — this is not a protocol weakness but a complete segmentation bypass.

For the access perspective — how mobile devices connect to wireless networks and the seven exposures that creates — see 5.9.6.

The Internet of Things (IoT) describes physical devices with sensors and software enabling them to connect, exchange data, and interact with their environment — including HVAC systems, smart thermostats, medical devices, printers, and badge readers. Embedded systems are specialised computing components (often microcontrollers) within larger systems, designed for limited specific functions. IoT controls are similar to mobile device controls (from 5.9.3) but must be adapted for constrained devices, remote deployments, and the absence of standard patch management.

IoT risks fall into three categories: business risk (health and safety, regulatory compliance, privacy, unexpected costs), operational risk (inappropriate access to device functionality, shadow use, performance degradation), and technical risk (device vulnerabilities, device updates, device management).

The eight key IoT technical vulnerabilities are: 1. Low software quality: quality of software in IoT devices is generally low because developers and end-users are unaware of potential security issues of embedded devices and their firmware. 2. Lack of encryption: most IoT devices do not implement encryption; account credentials traverse the network in clear text. 3. Low processing power: firmware runs on hardware with low-end computational power, limiting the security controls that can be applied. 4. Outdated hardware and software components: hardware and OS used in IoT may be outdated and contain exploitable vulnerabilities — attackers can run IoT botnets or eavesdrop on traffic. 5. Backdoor accounts: IoT devices may contain backdoor service accounts that bypass access controls and provide unauthorized access to organizational resources. 6. Poor device management: organizations often lack visibility into all IoT devices connected to disparate systems; remote connectivity leads to little insight into IoT security risk. 7. Interconnectedness: IoT devices are typically interconnected — if one device is compromised, the attack can spread to other devices or compromise the entire organizational network. This is the risk multiplier: a compromised IoT device on the corporate VLAN is a lateral movement path. Network segmentation (see 5.9.9) is the primary structural control. 8. Absence of inbuilt security: IoT devices often do not possess any inbuilt security features, making them a perfect target; disconnecting IoT devices when not in use reduces the attack surface.

IoT security controls include physical security (resilient components, IMEI lock for cellular IoT), remote access security (SIM-locking functionality, remote disable on physical breach detection), and network design (prefer private networks over public Wi-Fi for IoT communications). IS auditors should use audit procedures tailored to IoT — standard IT audit techniques do not account for embedded systems, low-processing devices, and physical-world connectivity. Many organizations require specific auditing procedures tailored to the challenges and risk specific to IoT environments.

Security is ultimately a human problem. Technical controls are necessary but insufficient if employees do not understand the threats they face or their responsibilities under security policies. A Security Education, Training, and Awareness (SETA) program addresses this human dimension at three levels. Awareness activities—posters, screensavers, phishing simulations, newsletters—keep security visible and change everyday behavior across all employees. Training delivers specific, role-based skills: IT staff learn secure configuration practices; HR staff learn data handling requirements. Education builds deep security knowledge for practitioners who design and manage security programs. An effective SETA program reduces incidents, improves policy compliance, and demonstrates to auditors and regulators that the organization actively manages its human risk. The IS auditor evaluates whether a SETA program covers all three levels, reaches all relevant populations, and measures behavioral outcomes—not just training completion rates.

Information security learning is structured as a continuum of three progressive tiers that differ in purpose, audience, depth, and measurement. Security awareness is the entry tier, targeted at all organizational personnel regardless of role. Its objective is not to impart technical skills but to change behavior — making employees more likely to recognize and report security threats such as phishing, social engineering, and physical security violations. Awareness activities include brief annual modules, phishing simulation campaigns, security reminder communications, and visual reminders in the workplace. Effectiveness is measured through behavioral metrics such as phishing simulation click rates and security incident reporting rates. Security training is the intermediate tier, targeted at personnel with specific security-relevant job functions — IT administrators, software developers, help desk staff, and other technical roles. Training imparts the specific knowledge and skills required to perform security-relevant tasks correctly, such as configuring security controls, responding to security incidents, or implementing secure coding practices. Effectiveness is measured through competency assessments and task performance metrics. Security education is the advanced tier, targeted at information security professionals who require deep theoretical and applied expertise. Education programs include professional certification preparation (CISA, CISSP, CISM), advanced coursework, research, and specialized security discipline training. Effectiveness is measured through certification achievement and demonstrated professional competency. IS auditors evaluate whether all three tiers are present, whether each reaches its intended audience, and whether program effectiveness is measured and reported to management.

A security awareness, training, and education (SATE) program delivers organizational value across four primary dimensions. Individual accountability: employees who have completed documented security training and signed acceptable use policies cannot credibly claim ignorance of security requirements when violations are investigated; this supports consistent enforcement of security policies, disciplinary actions for willful violations, and legal proceedings involving employee misconduct. Reduced human error: the majority of security incidents involve a human action — clicking a phishing link, misconfiguring a system, choosing a predictable password, or inadvertently disclosing sensitive information; awareness and training programs directly address these behaviors, reducing the frequency of human-initiated security incidents. Support for security controls: technical controls depend on human operators to function correctly — a firewall policy only works if administrators configure it properly; an access control system only works if managers promptly request account removals; an incident response plan only works if employees know to report suspicious activity. Training ensures that the human elements supporting technical controls operate as designed. Lower incident costs: organizations with effective SATE programs typically experience fewer security incidents, faster detection and response when incidents do occur, lower remediation costs, and reduced regulatory penalties and reputational damage — resulting in measurable financial benefits that support program investment justification.