ISO/IEC 27034 Foundation key terms

The discipline of protecting software applications from threats across their lifecycle by building controls into design, code, testing, deployment, and operation so that data and business logic are not compromised.

A documented management system of policies, objectives, processes, and responsibilities used by an organization to govern information risk and protect information assets in a systematic, repeatable way.

A structured process that embeds security activities such as threat modelling, secure coding, and security testing into each phase of software development rather than adding protection after release.

A design principle in which multiple independent layers of controls protect the same asset, so that failure or bypass of one control does not by itself expose the application or its data.

A principle requiring that users, services, and processes receive only the minimum access rights needed for their function and only for as long as needed, limiting the impact of misuse or compromise.

A defined measure that reduces application risk, expressed so it can be selected, implemented, verified, and traced to the requirements and threats it addresses within an application's lifecycle.

A curated catalogue of candidate application security controls, each with attributes such as objectives, verification methods, and maturity, from which controls are selected for a specific application.

The process of choosing which controls from the library apply to a given application, based on its risk profile, targeted assurance level, regulatory obligations, and business context.

The level of confidence in an application's security that an organization decides is appropriate for that application, given its risk, and against which implemented controls and evidence are judged.

The organization-wide process that establishes, operates, monitors, and improves application security, defining roles, activities, and decision points that apply to all applications in scope.

A management-approved statement of direction that sets mandatory expectations for application security, including scope, roles, control requirements, and consequences of non-compliance across the organization.

The sequence of security-relevant activities applied from an application's conception through design, build, deployment, operation, and retirement, ensuring controls remain effective as the application changes.

The ability to follow a documented link from business requirements and identified risks through selected controls to implementation evidence and verification results, demonstrating that nothing relevant was dropped.

Statements that specify what an application must do or provide to achieve its targeted assurance level, derived from risk assessment, policy, and selected controls, and used to judge acceptability.

A structured analysis that identifies threats and vulnerabilities relevant to an application, estimates likelihood and impact, and determines the level of risk so that controls can be prioritized.

An activity that systematically identifies potential attackers, attack paths, and assets at risk for an application, usually early in design, so that controls can be chosen to address specific threats.

A weakness in an application's design, code, configuration, or supporting environment that a threat could exploit to cause harm, and which verification activities are intended to find and remove.

The act of confirming, through review, testing, analysis, or evidence, that a selected control has actually been implemented and operates as intended in the application's real environment.

Confirmation that the implemented and verified controls actually satisfy the application's security requirements and business objectives, rather than merely existing as specified.

The justified confidence, supported by evidence, that an application meets its security requirements and that its controls are effective for the intended use and risk level.

A categorization of how much an application or component can be relied upon based on its assessed security posture, used to decide what interactions and data exchanges are acceptable.

The potential for loss or harm to the organization arising from weaknesses in an application, combining the likelihood of an adverse event with the business consequences if it occurs.

The risk that remains after selected controls have been implemented and verified, which must be understood and formally accepted by an accountable owner before the application is released.

The work of putting a selected control into practice in an application, including design decisions, coding, configuration, and supporting procedures needed to make the control effective.

Records such as test reports, review notes, configurations, and logs that demonstrate a control was implemented and verified, used to support assurance claims and audit findings.

The set of mechanisms that decide who or what may use a resource and in what manner, including authentication, authorization, and enforcement of permitted operations within an application.

A control that checks and constrains data entering an application so that malformed or malicious input cannot trigger injection, corruption, or unexpected behaviour in downstream processing.

The practice of writing software according to established security rules and patterns so that common weaknesses are avoided by construction rather than discovered and patched later.

Planned testing activities, including static analysis, dynamic testing, and penetration testing, that seek evidence about whether security controls work and whether exploitable weaknesses remain.

An authorized, simulated attack against an application to discover exploitable weaknesses and to demonstrate the practical effectiveness of its defensive controls under realistic conditions.

Planned education that gives developers, testers, and managers the knowledge and skills needed to perform their application security roles consistently and to recognize common weaknesses.

Management of security risk introduced by third-party components, libraries, and service providers, including their selection, monitoring, and the controls they must satisfy before integration.

A documented, time-bound, and formally approved deviation from an application security requirement, recording the justification, compensating controls, and the owner who accepts the associated risk.

An independent evaluation that determines whether an application's security processes and controls meet the requirements claimed, often performed by a party without a stake in the outcome.

The ongoing cycle of measuring application security performance, learning from incidents and assessments, and adjusting controls and processes so effectiveness increases over time.

An event that actually or potentially compromises an application's confidentiality, integrity, or availability, triggering defined response, containment, and lessons-learned activities.

The defined boundary identifying which applications, components, environments, and organizational units are subject to the application security management process and its control requirements.

The documented allocation of application security duties among business owners, developers, testers, security specialists, and management, ensuring each required activity has an accountable party.