Skip to main content
MuonPartners
Services
Architecture

Solution design and technology roadmapping

Solution AssessmentTechnology RoadmapsIntegration DesignSolution ArchitectureTechnical Design
Cyber Security

Security assessments, IAM, and compliance

AssessmentsIAMComplianceSecurity BaselineCyber Innovation
Network and Platform

Network architecture and cloud platforms

Network DesignCloud StrategyModernisation
Enterprise Architecture

Business-technology alignment

Business AlignmentPortfolio AnalysisGovernance
View all services
ProjectsCase StudiesInsightsToolsAbout
Contact Us

Services

Architecture
Solution AssessmentTechnology RoadmapsIntegration DesignSolution ArchitectureTechnical Design
Cyber Security
AssessmentsIAMComplianceSecurity BaselineCyber Innovation
Network and Platform
Network DesignCloud StrategyModernisation
Enterprise Architecture
Business AlignmentPortfolio AnalysisGovernance
ProjectsCase StudiesInsightsToolsAboutContact
Get in Touch
MuonPartners

Strategic technology consulting for Australian organisations navigating complexity.

Services

  • Architecture
  • Cyber Security
  • Network and Platform
  • Enterprise Architecture

Company

  • About
  • Products
  • Frameworks
  • Cross-Framework Mapping
  • Projects
  • Case Studies
  • Insights
  • Contact

Contact

  • [email protected]
  • Australia
  • LinkedIn

© 2026 Muon Partners. All rights reserved.

ABN 50 669 022 315 · A Muon Group company.

Privacy PolicyTerms of Service
  1. Frameworks
  2. >AESCSF
  3. >SITUATION
  4. >Establish And Maintain Situational Awareness
  5. >AESCSF-SITUATION-3g
AESCSF-SITUATION-3gActive

Predefined states of operation are documented and can be implemented based on the cybersecurity state of the function...

Statement

Predefined states of operation are documented and can be implemented based on the cybersecurity state of the function or when triggered by activities in other domains

Context and Guidance: Predefined states of operation are distinct operating modes (which typically include specific IT and OT configurations as well as alternate or modified procedures) that have been designed and implemented for the function and can be invoked by a manual or automated process in response to an event, a changing risk environment, or other sensory and awareness data to provide greater safety, resilience, reliability, and/or cybersecurity. Defining predefined states of operation typically requires use of detailed architectures or topologies, documentation and detailed understanding of your assets and their priorities (ASSET-1c, ASSET-1d), categories (ASSET-2c, ASSET-2d), and attributes (ASSET-1e, ASSET-2e). The defined states might include criteria for invoking the state, such as who has the authority to trigger a state change in either direction, checklists that must be completed before moving from a degraded state to an operational state, how long the organisation can survive in a particular state, or how the organisation will conduct monitoring to determine when the criteria are met. Information from monitoring activities is used to trigger decisions about invoking the predefined states of operation. For example, if monitoring activities indicate an outage, this might trigger a manual process in which some analysis is done that determines that not all operations can be supported, specific decision makers must sign off on temporarily curtailing nonessential operation, and a predefined state is invoked in which certain assets are shut down. Other situations might make use of an automated process. For example, based on threat intelligence received through monitoring activities (SITUATION-3f), a ruleset triggers an upgrade of the threat level, which triggers invocation of a predefined state that shuts down critical assets. Another example of predefined states of operations could be limiting communications between IT and OT environments during a cybersecurity incident. As another example, high-risk situations may be identified that warrant additional logging, such as a safety-related emergency that requires an immediate elevation of access privileges, but they also may increase the verbosity of logging on affected devices.

Related Practices • Input From: Implementing RESPONSE-3l and THREAT-2J provides input that may be useful for implementing this practice.

Location

Domain
SITUATION
Objective
Establish and Maintain Situational Awareness

Practice Details

Identifier
AESCSF-SITUATION-3g
Type
Practice
Domain
SITUATION
Objective
Establish and Maintain Situational Awareness

Maturity Level

MIL-1MIL-2MIL-3

Security Profile

SP-1SP-2SP-3
C2M2
C2M2-SITUATION-3Gequivalentvia derived-shared-practice-structure
ISO 27001
ISO27001-7.5relatedvia aescsf-reference
ISO27001-5.29relatedvia aescsf-reference
ISO27001-8.14relatedvia aescsf-reference
NIST CSF
NIST-CSF-ID.BE-5relatedvia aescsf-reference
View in graphReport an issue
← Back to Establish and Maintain Situational Awareness
Establish and Maintain Situational Awareness7 controls
AESCSF-SITUATION-3aMethods of communicating the current state of cybersecurity for the function are established and maintainedAESCSF-SITUATION-3bMonitoring data are aggregated to provide an understanding of the operational state of the functionAESCSF-SITUATION-3cRelevant information from across the organisation is available to enhance situational awarenessAESCSF-SITUATION-3dSituational awareness reporting requirements have been defined and address timely dissemination of cybersecurity info...AESCSF-SITUATION-3eRelevant information from outside the organisation is collected and made available across the organisation to enhance...AESCSF-SITUATION-3fA capability is established and maintained to aggregate, correlate, and analyse the outputs of cybersecurity monitori...AESCSF-SITUATION-3gPredefined states of operation are documented and can be implemented based on the cybersecurity state of the function...