A prohibited action is the harmful outcome a system must not allow an attacker to achieve. In security objectives, it should be specific, meaningful to the business, and high impact for at least one stakeholder. This turns abstract risk into an explicit security boundary that can be defended and evaluated.
What Prohibited Action Means in Security Objectives
A prohibited action is the specific harmful outcome a system must not allow. It converts broad threat language into a clear security boundary, so teams can define what “failure” means in business terms and measure whether the control set actually blocks it.
Why Security Objectives Need a Prohibited Action
Security objectives are strongest when they describe a concrete action, not a vague risk category. “Prevent unauthorized access” is useful, but “prevent transfer of funds above an approved threshold” or “prevent account takeover that changes recovery details” is more testable because the forbidden result is observable.
This framing helps close the gap between policy intent and system behaviour. It also makes it easier to compare controls, because the question becomes whether a control truly blocks the prohibited action rather than whether it simply adds friction.
How Prohibited Action Shapes Control Design
A prohibited action should be specific enough that engineers, security reviewers, and business owners would agree when it has occurred. That usually means describing the protected asset, the actor, the forbidden outcome, and the business impact that makes it unacceptable.
For example, a payment platform may prohibit creating a new payee and immediately releasing funds without a verified second approval. An identity platform may prohibit altering recovery factors after a suspicious session without step-up verification. The same pattern applies across systems: define the boundary in terms of the action that must never succeed.
How It Is Used in Evaluation and Assurance
Once the prohibited action is explicit, it becomes the basis for testing, logging, and control verification. Teams can ask whether a workflow blocks the outcome, whether monitoring would detect an attempt, and whether fallback paths accidentally re-enable it through a different route.
It also supports better risk communication. Stakeholders rarely align on abstract control language, but they usually understand the business consequence of a blocked or allowed action, which makes prioritisation and governance more defensible.
Risk and Threat Considerations
Vague objectives create gaps that attackers can exploit. If the prohibited action is not defined precisely, teams may protect the wrong precursor event while leaving an adjacent path open, or they may believe a control exists when it only slows the attack.
Failure mechanism: Ambiguous security boundaries let malicious or accidental actions pass through alternate workflows, exception paths, or insufficiently constrained integrations.
Impact: The result can be fraud, data loss, privilege abuse, or an integrity failure that the organisation only discovers after the business damage is done.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Least Privilege | Defines access boundaries that help prevent forbidden actions. |
| GV.RM-01 — Risk management strategy established and communicated | Turns the prohibited action into a governance target for risk decisions and acceptance. | |
| Recommendation — Map prohibited actions to least-privilege limits and verify users and systems cannot perform them. Document the prohibited action in the risk strategy so control owners can evaluate it consistently. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Limits what an authorised entity may do, matching the idea of blocking harmful outcomes. |
| AU-6 — Audit Review, Analysis, and Reporting | Supports verification that attempts to perform the prohibited action are visible and reviewable. | |
| Recommendation — Constrain permissions so the prohibited action cannot be executed through excess access. Log and review attempts that approach the prohibited action so assurance can be validated. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Requires access rules that can be aligned to defined forbidden outcomes. |
| Recommendation — Translate the prohibited action into access rules and enforce them consistently. | ||
Practitioner Guidance
Why practitioners should care: A prohibited action should be written so a control can be judged against a real outcome, not an interpretation. If different teams describe the forbidden result differently, assurance becomes inconsistent and gaps are easy to miss.
Practitioner takeaway: Treat the prohibited action as the testable end state, then align policy, control design, and monitoring to that exact outcome.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
