Dictionary · Web lookup drafts

An organization-defined parameter (ODP) placeholder used in risk-based security control frameworks — specifically in NIST SP 800-53 control SC-13 (Cryptographic Protection) and its derivatives such as SP 800-171 — that an organization is required to populate with the specific cryptographic mechanisms, standards, or algorithms it has selected for each designated cryptographic use case. ODPs of this kind are included in certain security requirements to provide flexibility through assignment and selection operations, allowing organizations to specify values tailored to their specific protection needs. In practice, it pairs with a companion ODP for "organization-defined cryptographic uses," so that for each use case an organization names, it must also designate the corresponding type of cryptography to implement. Acceptable values are drawn from applicable standards: generally applicable cryptographic standards include FIPS-validated cryptography and NSA-approved cryptography; for example, organizations protecting classified information may specify the use of NSA-approved cryptography.

A security control that temporarily suspends logical access to a system or device — requiring re-authentication before use resumes — when a session has been idle for a defined period or when a user steps away without logging out. Device locks are temporary actions taken to prevent logical access to organizational systems when users stop work and move away from the immediate vicinity of those systems but do not want to log out because of the temporary nature of their absences. The control is distinct from full session termination: device locks are not an acceptable substitute for logging out of the system (e.g., when organizations require users to log out at the end of workdays). In practice it is specified as a named access-control requirement — control AC-11 in NIST SP 800-53 and requirement 03.01.10 in NIST SP 800-171 — mandating both automatic triggering after inactivity and concealment of previously visible screen content, by concealing, via the device lock, information previously visible on the display with a publicly viewable image, and retaining the lock until the user reestablishes access using established identification and authentication procedures.

A recognized term of art in financial audit, internal audit, and enterprise risk management, the control environment is the set of standards, processes, and structures that provide the foundation for implementing internal control throughout an organization. It encompasses the overall attitude, awareness, and actions of directors and management regarding the internal control system and its importance to the entity, expressed through management style, corporate culture, values, organizational structure, and human resources policies and procedures. Codified as the foundational component of the COSO Internal Control–Integrated Framework, it provides guidance for setting the "tone at the top" and embedding a culture of ethical values and integrity throughout the organization; in the AICPA's SOC 2 Trust Services Criteria (CC1.0), it is assessed by examining how an organization establishes standards of conduct, evaluates adherence to those standards, and supports those values through training, communication of roles, and enforcement structures.

The foundational component of an organization's internal control system — specifically, the set of standards, processes, and structures that collectively establish the organizational conditions under which all other controls operate. As the AICPA characterizes it, it "sets the tone of an organization, influencing the control consciousness of its people" and is "the foundation for all other components of internal control, providing discipline and structure." It is shaped by the board of directors and senior management, who establish the "tone at the top" regarding the importance of internal control and expected standards of conduct. In practice, auditors and compliance professionals evaluate it across frameworks including COSO, the GAO Green Book, and AICPA attestation standards to assess whether an organization's governance posture, ethical culture, accountability structures, and oversight mechanisms are sufficient to support reliable control activities — making it the prerequisite condition assessed before any individual control is tested. The GAO Green Book identifies it as "the foundation for an internal control system," providing "the discipline and structure to help an entity achieve its" objectives.

This phrase is compositional rather than a term of art. It is ordinary English — a noun ("personnel") followed by a participial phrase ("responsible for [some function or asset]") — used throughout information security, privacy, and compliance documents to point to whichever individuals or roles hold accountability for a named control, system, or program. Its referent shifts entirely with context: it can denote a CISO, a site manager, an ISSO, a compliance owner, or any other role the surrounding text places in an accountable position. No authority document gives it a fixed, bounded definition independent of that surrounding context.

A **time-typed organization-defined parameter (ODP)** — a placeholder embedded in a security or privacy control statement that a deploying organization must replace with a concrete duration or interval during the control-tailoring process. Per the NIST Computer Security Resource Center glossary (sourced from NIST SP 800-37 Rev. 2 and SP 800-53 Rev. 5), an organization-defined control parameter is "the variable part of a control or control enhancement that can be instantiated by an organization during the tailoring process by either assigning an organization-defined value or selecting a value from a pre-defined list." "Organization-defined time period" is the time-dimensioned instance of that class of parameter: many NIST controls are not "complete" as published but require "fill in the blanks," and those blanks are called Organization-Defined Values or Organization-Defined Parameters. In practice it appears across a wide range of control families — account management, audit retention, identifier reuse, lockout windows, and more — wherever the standard mandates a time-bounded obligation but deliberately leaves the specific duration to organizational risk and policy judgment: for example, enforcing a limit on consecutive invalid logon attempts "during a [Assignment: organization-defined time period]" and then locking the account "for [Assignment: organization-defined time period]"; preventing "the reuse of identifiers for [Assignment: organization-defined time period]"; and disabling a user identifier "after [Assignment: organization-defined time period] of inactivity."

A level of access permission granted to an account that authorizes the holder to perform control, configuration, and administration functions on a system — such as installing software, modifying security settings, managing other accounts, or altering system behavior — that are withheld from standard users. Users who require administrative privileges on system accounts receive additional scrutiny by personnel responsible for approving such accounts and privileged access. Because IT personnel with administrative privileges can affect the security posture of an entire system, the field treats the expression as an authorization category subject to least-privilege controls, heightened authentication requirements, and continuous monitoring; administrative privileges are often required for malware to execute, making their governance a primary attack-surface concern. Users requiring administrative privileges on system accounts receive additional scrutiny by organizational personnel responsible for approving such accounts and privileged access, including system owner, mission or business owner, senior agency information security officer, or senior agency official for privacy.

A measured characteristic of an entity — a person, system, process, or condition — expressing the degree to which it threatens adverse consequences to confidentiality, integrity, or availability of assets. It is formally defined as "the effect of uncertainty on objectives pertaining to asset loss and the associated consequences" (NIST SP 800-160v1r1, drawing from ISO Guide 73). It is typically a function of two components: the adverse impacts that would arise if a threatening circumstance or event occurs, and the likelihood of that occurrence. In practice, the field applies the expression broadly — to technical configurations, personnel, third-party relationships, and operational conditions — and uses it as the object of management activities such as assessment, prioritization, treatment, and monitoring: risk that arises through the loss of confidentiality, integrity, or availability of information or information systems, considering impacts to organizational operations and assets, individuals, other organizations, and the Nation.

An organizational accountability role — typically held by a senior manager or executive — who bears primary responsibility for a mission or business function and, by extension, for the outcomes, risks, and resource decisions associated with the information systems that support that function. Distinguished from a system owner (who is accountable for a specific system) or a data owner (who classifies and governs a dataset), the business owner operates at the mission/business-process tier of enterprise governance: organizational missions and business functions influence the design and development of processes that carry them out, and the prioritization of those functions drives investment strategies, funding decisions, resource prioritization, and risk decisions. In practice, mission/business owners are among the roles to whom risk management decisions may be delegated, alongside systems and security engineers, enterprise architects, and authorizing officials. They are expected to coordinate closely with security, IT, and HR functions to ensure that the systems serving their mission areas are appropriately secured and that residual risk aligns with mission requirements — as reflected in working closely with program managers, the senior agency information security officer, and the business owners to ensure that all technical architecture requirements are adequately addressed.

A named organizational role—and the individual or group filling it—accountable for the installation, configuration, maintenance, and day-to-day operability of an information system or network on behalf of the organization. The role carries responsibility for overseeing day-to-day operability of a computer system or network, and it normally carries special privileges including access to the protection state and software of the system. In security and compliance frameworks, the role is distinguished from ordinary users and from governance roles (such as the authorizing official or CISO) by its hands-on technical custody: the system administrator implements approved secure baseline configurations, incorporates secure configuration settings for IT products, and conducts or assists with configuration monitoring activities. Authority documents enumerate it alongside other named organizational roles—such as human resource managers—because its elevated privileges and operational access make it a key control point for access management, configuration control, and policy enforcement; CNSSI 4009-2022 frames the role as the individual responsible for the installation and maintenance of an information system, providing effective utilization, adequate security parameters, and sound implementation of established policy and procedures.

A set of access rights or privileges — covering subjects such as users and processes, and objects such as files, systems, and data flows — that has been formally sanctioned through an organization's governance process (policy definition, role assignment, management decision, or regulatory requirement). The modifier "approved" distinguishes rights that have been deliberately granted and documented under an access control policy from rights that exist merely by default, misconfiguration, or implicit trust. In practice, standards such as NIST SP 800-53 (controls AC-3 and AC-4) and NIST SP 800-171 use the expression to describe what systems must actively enforce — whether for logical access to resources or for the flow of controlled information — rather than simply permit passively.

A governance instrument — sitting above models and mechanisms in the access-control abstraction stack — that states the high-level rules an organization adopts to determine which subjects (users or processes) may perform which operations on which objects (files, devices, records, domains). NIST places it as one of three design abstractions — policies, models, and mechanisms — where the policy layer supplies "high-level requirements that specify how access is managed and who may access information under what circumstances." In practice it takes named forms — identity-based, role-based, or attribute-based — and is paired with enforcement mechanisms such as access-control lists, matrices, or cryptography to mediate access between users or processes and objects such as devices, files, records, and domains. Specifying one is treated as a non-trivial engineering problem in its own right, because a system's security is more often compromised by access-control policy misconfiguration than by failures of cryptographic primitives.

A discrete information system — comprising hardware, software, firmware, and associated processes — that is owned, operated, or controlled within an organization's authorization boundary and subject to that organization's security and privacy controls. It is distinguished from external systems by its inclusion inside the boundary of authority where the organization directly governs the application of controls, and from the broader concept of "information system" by its relational, ownership-grounding modifier: the adjective scopes the system to a specific accountable entity. The field uses it as the standard unit of analysis in risk management, access control, and control assessment — the thing to which subjects and objects belong, against which security categories are assigned, and across which authorization decisions apply.

A category of security safeguard — comprising hardware features, software controls, operating procedures, and combinations thereof — that operationalizes an access control policy by actively permitting or denying subjects (users or processes) access to objects (files, devices, records, domains, programs). Examples canonically cited in NIST SP 800-53 include access control lists, access control matrices, and cryptography. Organizations pair these mechanisms with their chosen access control policies (identity-based, role-based, or rule-based) to govern access across the information system, and additionally deploy them at the application level when finer-grained protection is needed. In current practice under NIST SP 800-53 Rev. 5, they are explicitly extended to the application and service level to provide increased information security and privacy.

The set of specific, policy-derived enforcement mechanisms that constrain how information may move across boundaries within or between systems — governing the *path and channel* of data rather than who is authorized to read it. Distinguished from access control by its focus on transmission routes, content characteristics, and inter-system transfer conditions (e.g., blocking spoofed traffic, preventing cleartext export of controlled data, limiting proxy bypass), these restrictions operationalize an organization's information-flow control policy as enumerable, enforceable rules applied at network, application, and organizational boundaries. In practice, as articulated in NIST SP 800-53 AC-4, the concept governs where information can travel within and between systems — distinct from who is allowed to access it — with concrete examples such as blocking external traffic claiming an internal origin, keeping export-controlled information from being transmitted in the clear, and limiting transfers based on data structures and content.

A security property and architectural constraint that governs movement of data between domains of differing trust, classification, or integrity, requiring that data can travel in only one permitted direction across a boundary and cannot return or be exfiltrated in the opposite direction. Formal information-security models such as Bell-LaPadula and Biba favor this approach when information must be transferred between isolated networks of differing confidentiality or integrity. In practice, enforcement employs hardware mechanisms to enforce one-way information flows — such as optical data diodes — as well as software-based policy controls, preventing malware from entering a protected network while permitting remote monitoring and maintaining network isolation. Standards bodies such as NIST use the phrase operationally to denote a specific, enforceable mechanism within information flow control policy, not a general design preference: transferring CUI between systems that represent different security domains introduces the risk that such transfers violate domain security policies, and enforcement includes employing hardware mechanisms to enforce one-way information flows and implementing trustworthy regrading mechanisms to reassign security attributes and labels.

A validated, policy-governed control mechanism—technical, procedural, or architectural—used to reassign security and privacy attributes (such as classification labels) attached to information when that information moves across or between security domains with differing policies. It is a trusted process authorized to re-classify and re-label data in accordance with a defined policy exception. Organizations use validated regrading mechanisms to provide the requisite levels of assurance for attribute reassignment activities. In practice, implementing trustworthy regrading mechanisms to reassign security attributes and security labels is one of several enforcement options—alongside prohibiting transfers outright or using hardware-enforced one-way flows—applied at policy enforcement points where interconnected systems with different security policies exchange data.

The metadata fields carried in the structured prefix of a network packet or protocol message — such as source and destination addresses, port numbers, protocol identifiers, and routing directives — as distinct from the payload or body of that message. A packet consists of a header and a payload; the header contains parameters including source and destination addresses, port numbers, and protocol identifiers. Security and compliance controls use these fields as the primary decision surface for traffic enforcement: firewalls filter packets by examining header information separately from content information, while deep packet inspection extends analysis beyond header information into the contents of network traffic. The term applies across protocol layers and data formats — network packets, email messages, HTTP responses, and other structured data units all carry analogous header fields — and authority documents such as NIST SP 800-53 use it to distinguish the lighter-weight, faster class of filtering decisions (made on routing and addressing metadata alone) from content-based inspection. In the context of electronic mail, for example, header information means "the source, destination, and routing information attached to an electronic mail message, including the originating domain name and originating electronic mail address."

A discrete, identifiable unit of executable code — such as a library, module, driver, application, or package — that forms one layer of a larger system stack alongside hardware and firmware. In security and compliance frameworks (e.g., NIST SP 800-53, SP 800-161, and EO 14028 supply-chain guidance), it is used as a **compositional** inventory concept: practitioners enumerate software components as distinct, trackable artifacts that can individually carry vulnerabilities, provenance obligations, and integrity requirements. The term gains operational weight in contexts such as Software Bills of Materials (SBOMs), supply-chain risk management, and system-component inventories, where each software component must be identified, attributed to a supplier, and continuously monitored.

A compositional noun phrase, not a term of art. It describes, within the context of a separation-of-duties control, the personnel whose assigned roles or functions have been identified as needing to be divided across different people — i.e., those whose combined access to authorization, execution, recording, or audit functions would create an unacceptable conflict or fraud risk. Separation of duties addresses the potential for abuse of authorized privileges and reduces the risk of malevolent activity without collusion, including dividing mission functions and support functions among different individuals or roles and ensuring that those who administer access control functions do not also administer audit functions. The phrase appears as part of an assessment objective — "the duties of individuals requiring separation to reduce the risk of malevolent activity are defined" — where it modifies "duties" and simply points to whichever personnel hold roles that, per policy, must not be held by the same person.

A tailorable control parameter — an open slot in a security or privacy control statement — that an implementing organization fills in at the time of control tailoring by enumerating the specific subset of system information whose sensitivity to security-function integrity warrants protection under that control. The parent concept, *security-relevant information*, is defined by NIST as "information within the system that can potentially impact the operation of security functions or the provision of security services in a manner that could result in failure to enforce the system security policy or maintain isolation of code and data." Canonical examples include access control lists, filtering rules for routers or firewalls, configuration parameters for security services, and cryptographic key management information. In practice the full expression appears as an *Assignment* parameter inside a control statement — specifically, NIST SP 800-53 control AC-3(5) reads: "Prevent access to [Assignment: organization-defined security-relevant information] except during secure, non-operable system states" — meaning each organization must supply its own enumerated list of which security-relevant data assets that control governs, rather than accepting a single universal list; an organization-defined control parameter is formally "the variable part of a control or control enhancement that can be instantiated by an organization during the tailoring process by either assigning an organization-defined value or selecting a value from a pre-defined list provided as part of the control or control enhancement."

A structured placeholder — specifically an **assignment-operation control parameter** — embedded in a security or privacy control statement to mark the temporal cadence of a recurring activity as a value that each implementing organization must determine and document for itself during the control-tailoring process. It is formally defined in NIST SP 800-53 as "a control parameter that allows an organization to assign a specific, organization-defined value to the control or control enhancement," with frequency of testing cited as the canonical example of such an assignment. More broadly, NIST defines the class to which it belongs — the organization-defined control parameter — as "the variable part of a control or control enhancement that can be instantiated by an organization during the tailoring process by either assigning an organization-defined value or selecting a value from a pre-defined list." In practice, the expression functions as a deliberate blank in a control's text — appearing in brackets as `[Assignment: organization-defined frequency]` — which the implementing organization fills with a concrete interval (e.g., annually, quarterly, after each major change) that reflects its own risk management strategy, since the entity is expected to select a value appropriate for the organization.

Actionable intelligence about weaknesses, exposures, and attack conditions in systems, software, or infrastructure that a security program collects, standardizes, and acts upon. It is distinguished from the raw concept of a "vulnerability" by encompassing the full surrounding data set — identifiers (e.g., CVE), severity scores (CVSS), affected platforms, exploitation conditions, remediation guidance, and disclosure timelines — that make a weakness operationally meaningful. In practice, the field produces, exchanges, and consumes it through structured repositories and standards (NVD, CVE, OVAL, SCAP) and through monitored feeds — public and private — that organizations track continuously to drive patching, configuration management, risk assessment, and access-control decisions.

A discrete, adjustable setting — such as a named variable and its assigned value — that governs the behavior, capability, or security posture of a hardware, software, or firmware component. Configuration parameters are distinguished from one another by the breadth of what they control: individually each represents a single knob (e.g., maximum password length, an allowed port, a timeout interval), but collectively they constitute the full configuration surface of a system and, together, determine whether that system meets an organization's security baseline. In security-focused configuration management, practitioners enumerate, assign values to, document, and monitor these parameters to enforce least-privilege operation and to detect unauthorized drift — covering components as varied as operating systems, network devices, and cryptographic modules.

A placeholder value within a security or privacy control statement — specifically an instance of an assignment operation — that the implementing organization is required to populate during control tailoring by naming the specific individuals, positions, or functional roles to which a given control obligation applies. NIST SP 800-53 Rev. 5 defines an assignment operation as "a control parameter that allows an organization to assign a specific, organization-defined value to the control or control enhancement (e.g., assigning a list of roles to be notified)." In practice, wherever the bracket notation `[Assignment: organization-defined personnel or roles]` appears in a control, the organization instantiates that variable "during the tailoring process by either assigning an organization-defined value or selecting a value from a predefined list provided as part of the control or control enhancement," thereby converting the generic control statement into an enforceable, organization-specific obligation targeting named staff or role designations.

A managed user or system account credential whose permissions are explicitly bounded to ordinary, non-administrative tasks — it cannot invoke security functions, modify system configuration, or access restricted data without a separate elevation step. As defined by NIST SP 800-53 (AC-6(2)) and NIST SP 800-171 (3.1.6), privileged accounts are granted elevated privileges to access resources — including security functions or security-relevant information — that are otherwise restricted for non-privileged accounts; a non-privileged account is therefore the contrasting account type that operates below that threshold. The field uses the term to enforce the principle of least privilege through dual-account practice: privileged users are required to use separate non-privileged accounts for routine tasks unrelated to system or security administration, and general computing activities — such as internet browsing, email, and productivity suite use — are conducted from the user's primary, non-privileged account (CIS Controls). The term encompasses any account type that sits below the privileged threshold — standard user accounts and guest accounts are considered non-privileged, since they are given limited access to systems and data — and applies equally to role-based constructs: the inclusion of roles addresses situations where a change of role provides the same degree of assurance in the change of access authorizations as would be provided by a change between a privileged and non-privileged account.

A compositional phrase, not a term of art. It is used in plain-language contrast within a given document to distinguish information whose subject matter, classification, or handling requirements relate to security functions from information that does not — for example, routine operational, administrative, or business-process records that happen to reside in the same system or log stream as security-relevant data. No standards body (NIST, ISO, AICPA, CIS, or any regulator) has assigned it a standardized, bounded meaning distinct from its component words.

A level of access permission — assigned to an account, process, or identity — that exceeds the baseline rights granted to ordinary users, authorizing operations (such as modifying system configuration, accessing restricted resources, or executing security-critical functions) that are withheld from standard accounts. Privileged accounts are those "granted elevated privileges to access resources (including security functions or security-relevant information) that are otherwise restricted for non-privileged accounts," per NIST SP 800-171r3; at the network level, NIST SP 800-50r1 defines this as a condition typically allocated to system administrators, network administrators, DBAs, and others responsible for system/application control, monitoring, or administration. The field uses the expression both as a property of legitimately authorized accounts and as a target state in adversarial contexts: software applications or processes may need to execute with elevated privileges to perform required functions, but this can indirectly provide users with greater privileges than those formally assigned to them; conversely, elevated privileges are important to bypass safety mechanisms of industrial controllers, and can also be used to bypass access controls or security mechanisms more broadly.

A privileged user account that holds elevated, often unrestricted rights over a system or environment — encompassing administrative control of files, commands, configurations, audit logs, and security settings — beyond what ordinary users are permitted. NIST SP 800-53 (AC-6(5)) places super user accounts within the broader class of privileged accounts, noting they are "typically described as system administrator for various types of commercial off-the-shelf operating systems." NIST SP 1800-18 uses the term to describe accounts that system administrators employ "to manage information technology (IT) infrastructures and resources or to access high-value applications (e.g., payment systems, accounting systems) and core systems." In compliance and access-control practice, the field uses the expression as a category label for the highest-privilege managed account object — distinct from the individual who holds it — and subjects it to controls such as MFA, separation from day-to-day accounts, and enhanced audit oversight; because even auditing services are not immune from such an account, its potential for damage — inadvertent or intentional — is considered very significant for organizations with regulatory compliance requirements.

This phrase is compositional rather than a term of art. The field has a well-established coined term — intrusion detection and prevention system (IDPS), "a network monitoring strategy that supports threat detection by passively monitoring traffic and actively blocking suspicious or malicious behavior once it is flagged" — standardized in documents such as NIST SP 800-94 and ISO/IEC 27039. "Intrusion detection involves monitoring system or network activities for signs of security violations, while intrusion prevention extends this capability by actively mitigating detected threats"; due to overlapping functionalities, the combined term IDPS is commonly used. "Intrusion detection and prevention mechanism" is simply a descriptive paraphrase that substitutes the generic word *mechanism* for *system*, and carries no distinct or specialized meaning beyond what "IDPS" already conveys.

A category of system principal whose access rights are bounded to standard, everyday functions and explicitly exclude the elevated capabilities — such as security-relevant operations, administrative configuration, or system-control functions — that require formal authorization to exercise. The distinguishing feature is not the absence of any access, but the absence of *elevated* access: nonprivileged users hold only the baseline entitlements that ordinary task performance demands, in contrast to privileged users who are authorized (and therefore trusted) to perform functions ordinary users are not permitted to perform. Across NIST SP 800-53, SP 800-171, and related federal standards, the expression anchors access-control requirements — particularly least-privilege controls — that prohibit such users from executing privileged functions, mandate separate accounts when the same individual holds both roles, and identify security-sensitive resources that must be shielded from them.

A procedural or technical capability — whether a software routine, an administrative role, or a system component — that implements and enforces an access control policy by evaluating requests from subjects against authorization rules and producing a permit or deny outcome. A security administration function specifies the authorization database that acts as an input to the access control function, meaning the phrase denotes the enforcement side of the access control pipeline, distinct from the policy-definition and audit sides. Authority documents such as NIST SP 800-53 use it in separation-of-duties contexts — for example, requiring that personnel who administer access control functions do not also administer audit functions — confirming that it names an identifiable, separable operational or technical role rather than the whole discipline of access control.

A formal inter-organizational instrument — such as an Interconnection Security Agreement (ISA), Memorandum of Understanding (MOU), Information Exchange Security Agreement (IESA), or equivalent contract — that documents the technical, security, and privacy conditions under which data may move between two systems or organizations that operate under different security or privacy domains. It must document interface characteristics, security and privacy requirements, applicable controls, and each party's responsibilities for each system. Because transferring information between systems in different security or privacy domains introduces the risk of violating one or more domain policies, such agreements establish where policy enforcement points sit and who provides guidance at them. In practice, the agreement can take several forms depending on relationship and risk level, including ISAs, IESAs, MOUs, SLAs, user agreements, and NDAs.

A policy threshold — either a duration or a described condition — that an organization defines to represent a session or period during which a user is not expected to interact with a system. It functions as the trigger criterion in session-management controls: NIST SP 800-53 AC-2(5) requires that "users log out when [Assignment: organization-defined time period of expected inactivity or description of when to log out]." The concept is intentionally broader than a simple countdown timer: the organization may supply either an "organization-defined time-period of expected inactivity" or a "description of when to log out," accommodating both quantitative thresholds and qualitative, scenario-based conditions. The control is behavior- or policy-based and requires users to take physical action to log out when they are expecting inactivity longer than the defined period.

A category of human workforce member recognized in governance, risk, and compliance frameworks — specifically, an individual who is employed by an external vendor organization but whose work, access, or conduct is relevant to the engaging entity's control environment. Distinguished from direct employees and independent contractors, vendor employees are natural persons on another organization's payroll who nonetheless touch the engaging entity's systems, data, processes, or physical premises; the engaging entity does not control the employment relationship but is responsible for extending its security, ethics, and competency standards to cover them. In practice, frameworks such as the AICPA SOC 2 Trust Services Criteria treat vendor employees alongside contractors as a third class of in-scope workforce — persons who must be vetted for background and technical competency, trained on applicable standards, and held to codes of conduct — precisely because their employment by a separate legal entity does not relieve the engaging entity of responsibility for the risks they introduce.

A mandatory, foundational program of security and privacy instruction that an organization delivers to personnel at the point of onboarding or before access to systems is granted, establishing baseline awareness of policies, risks, and responsibilities before any ongoing or periodic refresher training begins. It is distinguished from recurring annual or ad hoc training by its timing—it is a prerequisite condition for system access—and by its comprehensive scope, covering the full range of applicable security and privacy obligations rather than incremental or topical updates. Across the field, it anchors a two-phase training lifecycle: the initial delivery sets the baseline, and subsequent periodic cycles (annual, event-triggered, or role-change-triggered) build upon it.

This phrase is **compositional**, not a term of art. It combines two ordinary access-control concepts — "privilege" (an elevated permission or right granted to a user or role) and "audit-related" (pertaining to the logging, monitoring, and review functions of a system) — to describe the subset of elevated permissions whose scope is limited to audit activities such as reading logs, generating audit reports, or reviewing security events, as opposed to administrative or operational privileges that modify system state. Authority documents such as NIST SP 800-53 (AC-6, AU family) treat these concepts separately rather than coining a compound term; when writers need to distinguish audit-function access from other privileged access, they assemble the phrase on the fly using those established concepts.

A policy-specified duration — set by an organization based on its risk tolerance, regulatory obligations, and operational context — that serves as the threshold triggering a required security or compliance action. Standards bodies (NIST SP 800-53, SP 800-171, CMMC, ISO/IEC 27001) deliberately leave the numeric value as an organizational assignment, expressed in NIST controls as `[Assignment: organization-defined time period]`; once an organization fills in that value and documents it in policy, it becomes the "defined period" that governs enforcement. The expression appears across multiple control domains — session inactivity logout, account and identifier disablement, identifier-reuse prohibition, and data retention — always denoting the same underlying concept: the documented, policy-anchored time boundary after which a specific protective action must automatically or procedurally occur.

A formally assigned governance role, held by a senior body such as a board of directors or designated oversight authority, whose defining feature is the duty to monitor, evaluate, and be accountable for an organization's compliance with established security, privacy, or regulatory requirements—without necessarily operating the controls directly. The role entails establishing accountability and providing "active support and oversight of monitoring and improvement" for security and privacy programs. In practice, documents such as the California OIS Information Security Policy Compliance and Enforcement Standard use the phrase to describe how a governing body "exercises its oversight responsibilities and the consequences of non-compliance with information security and privacy policies." Across NIST, AICPA, and FISMA-aligned frameworks the concept functions as the governance-layer counterpart to operational responsibility: it fixes *who is answerable* for whether controls exist and remain effective, distinct from *who implements* those controls, and it is discharged through mechanisms such as board review cycles, reporting to senior leadership, and acceptance of organizational risk posture. NIST SP 800-53 treats it as a distinct role category, explicitly listing "individuals with system, information security, privacy, or risk management and oversight responsibilities" as a separate audience from implementers and assessors.

A compositional phrase, not a term of art. The words "comprehensive," "authorized software," and "process" each carry their ordinary security-configuration meanings — respectively, covering multiple levels of abstraction, limiting execution to explicitly permitted code, and the organizational lifecycle (identification, enforcement, and periodic review) for doing so. The phrase describes the goal that an allowlisting program should span all software layers (applications, modules, APIs, system services, kernel functions, drivers, etc.) rather than operating only at the application level, but it is not defined, scoped, or used as a standalone concept anywhere in the standards corpus.

A rule set or named security requirement that specifies which subjects, information objects, and operations are permitted to move data between security domains, classification levels, or trust boundaries — governing *where* information may travel rather than merely *who* may access a container. It regulates where information can travel within a system and between systems, in contrast to who is allowed to access the information, and without regard to subsequent accesses to that information. In the Common Criteria framework, an information flow control policy controls access to the information, independent of its container, and its scope of control is characterised by three sets: the subjects under control of the policy, the information under control of the policy, and the operations which cause controlled information to flow to and from controlled subjects. In practice, organizations use such policies as the basis for enforcement mechanisms — firewalls, content filters, cross-domain guards, and label-based routing rules — to control the flow of information between designated sources and destinations within systems and between connected systems, with flow control based on the characteristics of the information and/or the information path.

A collective label for the hardware, firmware, and software components — such as firewalls, boundary protection devices, deep-packet inspection engines, and content-analysis tools — that an organization deploys to examine and selectively allow or block information flows based on defined rules or policies. Organizations commonly employ information flow control policies and enforcement mechanisms to control the flow of information between designated sources and destinations; enforcement occurs in boundary protection devices that employ rule sets, packet-filtering based on header information, or message-filtering based on message content. The expression is used in security control contexts — particularly information flow enforcement — to flag that the *trustworthiness* of these components is itself a security concern: organizations consider the trustworthiness of filtering and/or inspection mechanisms (i.e., hardware, firmware, and software components) that are critical to information flow enforcement. In practice the field uses the phrase as an umbrella that covers a spectrum from simple packet filters to advanced cross-domain solutions, including redundant/independent filtering mechanisms, linear filter pipelines, filter orchestration engines, and filter mechanisms using multiple processes — all evaluated together as a class of security-critical infrastructure.

A layer-scoped enforcement boundary within an authorized-software (allowlisting) control regime, specifically the granularity at which permitted-execution policy is applied to discrete, named software applications as whole units. It distinguishes coarse-grained controls that identify and permit or deny execution at the application boundary from finer-grained controls operating below that boundary — at the levels of APIs, modules, scripts, system processes, kernel functions, drivers, and dynamic-link libraries. The field uses it as a reference point for characterizing the *depth* of an allowlisting implementation: controls that act only at this layer can be bypassed by malicious code embedded within or loaded by an already-authorized application, which is why standards guidance calls for decomposing and monitoring software at sub-application levels to close that gap.

A set of permissions, capabilities, or access rights formally granted by an organizational authority to a user, process, or role, scoped to what is necessary for that principal to perform assigned functions. It is distinguished from unauthorized or incidentally acquired access in that it reflects a deliberate policy decision — typically documented through access authorization processes, role definitions, or least-privilege analysis — about what elevated actions a given subject may legitimately take. In practice, standards bodies use the concept as a risk object: separation of duties addresses the potential for abuse of authorized privileges and helps to reduce the risk of malevolent activity without collusion (NIST SP 800-53 Rev. 5, AC-5), and the principle of least privilege is applied with the goal of authorized privileges no higher than necessary to accomplish required organizational missions or business functions (NIST SP 800-171 Rev. 2, control 3.1.5), meaning that "authorized privilege" names the bounded, sanctioned entitlement set that controls must constrain and audit rather than any specific privilege type.

A category of organizational activity comprising the substantive, operational work that an organization exists to perform — its core business or programmatic responsibilities — as distinguished from the technical and administrative activities (such as system management, configuration management, or auditing) that support those operations. In NIST SP 800-53 and NIST SP 800-171, it appears explicitly in the separation of duties control, which calls for "dividing mission functions and support functions among different individuals or roles" to reduce the potential for abuse of authorized privileges and the risk of malevolent activity without collusion. The phrase is compositional rather than a defined term of art: its meaning is fully recoverable from its parts ("mission" = the organization's core purpose; "functions" = the activities that serve it), and it carries no specialized technical meaning beyond that ordinary composition.

A placeholder value in a security or privacy control statement — specifically an **assignment operation** — that an implementing organization fills in during tailoring to name the exact endpoints, hardware types, or classes of endpoint (workstations, servers, mobile devices, IoT sensors, personally-owned BYOD assets, etc.) to which the control applies. It is the variable part of a control or control enhancement that is instantiated by an organization during the tailoring process by assigning an organization-defined value or selecting a value from a predefined list. The expression's force is not "a device of a particular kind" but rather "whichever devices or device types the organization has formally decided belong inside the scope of this requirement": devices requiring identification and authentication are defined by type, device, or a combination, and the category explicitly includes devices not owned by the organization. In practice it gives organizations the latitude described by NIST SP 800-53: organizations can restrict the application of the control to a limited number or type of devices based on mission or business needs, while still committing to a specific, auditable scope once the parameter is set. Once specified, the values for the assignment and selection statements become a permanent part of the control.

A recognized security-control category covering any approved location where an employee conducts official organizational work outside the organization's primary or owned facility — including private residences, satellite offices, co-working spaces, government facilities, and hotel or similar transient environments. It is distinguished from "alternate processing site" (a DR/BCP concept for relocating IT systems) and from "remote access" (a network-layer concept): its focus is on the physical and operational security posture of the place of work itself. Frameworks such as NIST SP 800-53 (PE-17) and NIST SP 800-171 (3.10.6 / 03.10.06) treat it as a named control within the Physical Protection family, requiring organizations to enumerate approved sites, apply organization-defined security requirements to each, assess control effectiveness, and maintain an incident-reporting channel for personnel working at those locations.

A physical-protection control category covering the full set of supervisory and monitoring measures applied to any person who lacks permanent access authorization while that person is present inside a controlled facility or secure area. It is distinguished from general access control by its temporal and custodial character: the organization must actively manage what the non-credentialed individual does — where they go, what they touch or observe, and whether they depart without incident — rather than merely verifying identity at entry. In NIST frameworks it sits within the Physical Protection control family; individuals with permanent physical access authorization credentials are explicitly excluded from the visitor category, and audit logs are a recognized mechanism for carrying out the monitoring obligation. In practice, implementation encompasses identifying and signing in visitors, escorting them, controlling which areas they may enter (especially where sensitive systems or data reside), logging their presence and movements, and applying additional safeguards to protect controlled information during and after their presence.

A physical infrastructure component — a rigid, open or enclosed channel mounted overhead, underfloor, or along walls — used to route, support, and protect bundles of network, power, and telecommunications cables across a facility. In information security and compliance, cable trays function as a **physical safeguard for transmission media**: by enclosing cable runs in a structured, identifiable pathway, they reduce the risk of unauthorized access, physical tampering, accidental damage, and eavesdropping on unencrypted signals traversing those cables. Standards frameworks (NIST SP 800-53 PE-4, NIST SP 800-171 §3.10.2, ISO/IEC 27001 Control 7.12) enumerate them alongside locked wiring closets, conduit, and wiretap sensors as co-equal controls for protecting cabling infrastructure — making the phrase **compositional** in origin (it describes the physical object) but **used as a recognized term of art** within the physical-protection control family whenever physical access control over transmission media is addressed.

A security control mechanism by which a user, through deliberate physical action, places a system or endpoint into a locked state that blocks further logical access until re-authentication — as opposed to locks triggered automatically by elapsed inactivity timers or by proximity/environmental sensors. Device locks in general are temporary actions taken to prevent logical access to organizational systems when users stop work and move away from the immediate vicinity of those systems but do not want to log out because of the temporary nature of their absences. User-initiated device locking is behavior- or policy-based and requires users to take physical action to initiate the device lock. In access-control frameworks it is used to distinguish the voluntary, human-triggered pathway to a session lock from automatic, timer-driven or sensor-driven pathways, and it is enforced either as a behavioral expectation or as an explicit organizational policy requirement applied under controls such as NIST SP 800-53 AC-11.

A relational security concept used to identify the source side of a resource-reuse threat: any principal — whether a human user, an assigned role, or a process acting on behalf of either — whose session has ended and whose allocated system resources (memory, cache, disk sectors, registers, etc.) have been returned to the system for reassignment. The concern is that information produced by the actions of prior users or roles may remain accessible to any current users or roles that obtain access to those shared system resources after the resources have been released back to the system. The phrase appears consistently in the object-reuse and residual-information-protection family of controls, where it anchors the threat model by naming the unintended originator of residual data, as opposed to the successor principal who must be denied access to it. This problem domain is commonly referred to as object reuse and residual information protection, covering shared resources such as registers, cache memory, main memory, and hard disks.

A policy parameter placeholder used in risk-based access-control frameworks — specifically the customizable slot within a re-authentication control statement that an organization fills with its own enumerated list of trigger conditions. Organizations are expected to specify events or states that invalidate the assurance level of an existing session, such as role changes, credential updates, escalation to privileged functions, elapsed time thresholds, or changes in system security category. In practice the expression functions as an assignment variable: it signals that the standard body intentionally defers the concrete trigger list to the implementing organization rather than prescribing a universal set, so that the control scales across different risk environments and mission contexts.

An application classification assigned through impact analysis to any software system whose loss of availability, loss of integrity, or unauthorized access would materially impair an organization's mission, revenue, regulatory standing, or public safety obligations. It is distinguished from ordinary applications by the severity and breadth of harm its failure produces — not by its technical architecture — and the classification is operationalized by mandating a proportionately higher tier of security controls: stronger access governance, elevated monitoring priority, stricter change approval, and dedicated incident-response treatment. In federal and compliance frameworks, the category maps directly to what OMB Circular A-130 and NIST SP 800-18 call a "major application," meaning one that "requires special attention to security due to the risk and magnitude of harm resulting from the loss, misuse, or unauthorized access to or modification of the information in the application," because "certain applications, because of the information in them, require special management oversight and should be treated as major."

A risk-management mechanism — either in-house or contracted externally — by which an organization maintains patches, updates, maintenance, and technical assistance for system components whose original vendor, developer, or manufacturer has ceased providing support. It is distinguished from ordinary vendor support by the fact that the original support chain has ended: the organization must actively procure or develop a substitute, such as custom patch development, third-party extended-support contracts, or open-source value-added provider arrangements. In practice the field invokes the concept specifically under controls governing unsupported or end-of-life system components that cannot be immediately replaced because they remain essential to mission or business operations — requiring documented organizational decisions about acceptable risk alongside the chosen support mechanism.

A category of federal entity — a government-chartered corporation whose capital is entirely owned by the United States Government — that falls within the scope of federal information-security and privacy compliance obligations. It is distinguished from a mixed-ownership government corporation (whose capital is partly privately held) and from a conventional executive department or independent establishment, but is treated as an equivalent compliance subject when it is "fully subject to the provisions of 31 U.S.C. Chapter 91" (the Government Corporation Control Act). In U.S. federal compliance frameworks such as FIPS 199/200 and NIST SP 800-60, the phrase appears as the fourth limb of the defined term "executive agency," thereby bringing these corporate entities within FISMA's information-security categorization, audit, and control requirements alongside ordinary cabinet departments and military departments.

A category of security control — specifically, the application of cryptographic mechanisms (such as encryption, hashing, message authentication codes, or digital signatures) to enforce one or more security properties — confidentiality, integrity, authenticity, and non-repudiation — for data at rest, in transit, or in backup. Cryptography can provide several security services: confidentiality, identity authentication, data integrity authentication, source authentication, and support for non-repudiation. In standards practice, the expression names a named control enhancement: NIST SP 800-53 uses "Cryptographic Protection" as an enhancement under System and Communications Protection, requiring that information systems implement cryptographic mechanisms to prevent unauthorized disclosure and modification of defined information on defined system components. The field applies it broadly across contexts — covering transmission confidentiality and integrity, backup information, and storage — wherever cryptographic mechanisms are the chosen means of enforcing a security requirement, with the specific operation depending on the algorithm: encrypting or signing data, generating a hash or MAC, or establishing keys.