Dependent failure analysis (DFA) looks for common cause and cascading failures among blocks on the same die and between hardware and software, judges how likely they are to breach a safety goal or a requirement derived from one and defines mitigating safety measures, to evaluate weaknesses in the safety concept and to evidence the independence required by ASIL decomposition (ISO 26262-9 clause 5) or freedom from interference from coexistence analysis (ISO 26262-9 clause 6); a dependent failure initiator (DFI) is one underlying cause that, through coupling factors, brings down several elements at once, with a starting list of systematic, environmental and random hardware DFIs (Tables 21 to 26), some of which (shared resources, interfering elements such as a DMA corrupting other elements' resources) are handled in the standard safety analysis as residual, single-point or multiple-point faults while the rest are addressed qualitatively; the guidance distinguishes cascading from common cause failures, gives the DFI and mitigation measure list, a DFA workflow and worked examples including dependent failures between software and hardware elements.
This control maps to 1 controls across 1 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.
Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.
The graph holds this control, the 1 it maps to, and the evidence behind each claim, over MCP and REST.