resolved duplicity of files
This commit is contained in:
parent
4505c4105e
commit
2fbe163fff
121 changed files with 6 additions and 1531 deletions
BIN
.DS_Store
vendored
BIN
.DS_Store
vendored
Binary file not shown.
|
|
@ -3,8 +3,10 @@
|
|||
|
||||
### Control
|
||||
Allocation and management of authentication information should be controlled by a management process, including advising personnel on the appropriate handling of authentication information.
|
||||
|
||||
### Purpose
|
||||
To ensure proper entity authentication and prevent failures of authentication processes.
|
||||
|
||||
### Guidance
|
||||
|
||||
**Allocation of authentication information**
|
||||
|
|
@ -63,7 +65,7 @@ h) store and transmit passwords in protected form.
|
|||
|
||||
Password encryption and hashing should be performed according to approved cryptographic techniques for passwords (see 8.24).
|
||||
|
||||
**Other** **information**
|
||||
**Other information**
|
||||
|
||||
Passwords or passphrases are a commonly used type of authentication information and are a common means of verifying a user’s identity. Other types of authentication information are cryptographic keys, data stored on hardware tokens (e.g. smart cards) that produce authentication codes and biometric data such as iris scans or fingerprints. Additional information can be found in the ISO/IEC 24760 series.
|
||||
|
||||
|
|
@ -3,8 +3,10 @@
|
|||
|
||||
#### Control
|
||||
Management should require all personnel to apply information security in accordance with the established information security policy, topic-specific policies and procedures of the organization.
|
||||
|
||||
#### Purpose
|
||||
To ensure management understand their role in information security and undertake actions aiming to ensure all personnel are aware of and fulfill their information security responsibilities.
|
||||
|
||||
#### Guidance
|
||||
Management should demonstrate support of the information security policy, topic-specific policies, procedures and information security controls.
|
||||
|
||||
|
|
@ -25,5 +27,6 @@ f) continue to have the appropriate information security skills and qualifica
|
|||
g) where practicable, are provided with a confidential channel for reporting violations of information security policy, topic-specific policies or procedures for information security (“whistleblowing”). This can allow for anonymous reporting, or have provisions to ensure that knowledge of the identity of the reporter is known only to those who need to deal with such reports;
|
||||
|
||||
h) are provided with adequate resources and project planning time for implementing the organization’s security-related processes and controls.
|
||||
|
||||
#### Other information
|
||||
No other information.
|
||||
|
|
@ -2,35 +2,17 @@
|
|||
## 5.5 Contact with authorities
|
||||
|
||||
#### Control
|
||||
|
||||
|
||||
|
||||
The organization should establish and maintain contact with relevant authorities.
|
||||
|
||||
#### Purpose
|
||||
|
||||
To ensure appropriate flow of information takes place with respect to information security between the organization and relevant legal, regulatory and supervisory authorities.
|
||||
|
||||
|
||||
|
||||
#### Guidance
|
||||
|
||||
|
||||
|
||||
The organization should specify when and by whom authorities (e.g. law enforcement, regulatory bodies, supervisory authorities) should be contacted and how identified information security incidents should be reported in a timely manner.
|
||||
|
||||
|
||||
|
||||
Contacts with authorities should also be used to facilitate the understanding about the current and upcoming expectations of these authorities (e.g. applicable information security regulations).
|
||||
|
||||
|
||||
|
||||
#### Other information
|
||||
|
||||
|
||||
|
||||
Organizations under attack can request authorities to take action against the attack source.
|
||||
|
||||
|
||||
|
||||
Maintaining such contacts can be a requirement to support information security incident management (see 5.24 to 5.28) or the contingency planning and business continuity processes (see 5.29 and 5.30). Contacts with regulatory bodies are also useful to anticipate and prepare for upcoming changes in relevant laws or regulations that affect the organization. Contacts with other authorities include utilities, emergency services, electricity suppliers and health and safety [e.g. fire departments (in connection with business continuity), telecommunication providers (in connection with line routing and availability) and water suppliers (in connection with cooling facilities for equipment)].
|
||||
|
|
@ -23,7 +23,6 @@ e) share and exchange information about new technologies, produ
|
|||
|
||||
f) provide suitable liaison points when dealing with information security incidents (see 5.24 to 5.28).
|
||||
|
||||
|
||||
|
||||
#### Other information
|
||||
No other information.
|
||||
|
|
@ -1,74 +0,0 @@
|
|||
#iso27002/2022/EN
|
||||
## 5.1 Policies for information security
|
||||
|
||||
#### Control
|
||||
Information security policy and topic-specific policies should be defined, approved by management, published, communicated to and acknowledged by relevant personnel and relevant interested parties, and reviewed at planned intervals and if significant changes occur.
|
||||
#### Purpose
|
||||
To ensure continuing suitability, adequacy, effectiveness of management direction and support for information security in accordance with business, legal, statutory, regulatory and contractual requirements.
|
||||
#### Guidance
|
||||
At the highest level, the organization should define an “information security policy” which is approved by top management and which sets out the organization’s approach to managing its information security.
|
||||
|
||||
The information security policy should take into consideration requirements derived from:
|
||||
|
||||
a) business strategy and requirements;
|
||||
b) regulations, legislation and contracts;
|
||||
c) the current and projected information security risks and threats.
|
||||
|
||||
The information security policy should contain statements concerning:
|
||||
|
||||
a) definition of information security;
|
||||
b) information security objectives or the framework for setting information security objectives;
|
||||
c) principles to guide all activities relating to information security;
|
||||
d) commitment to satisfy applicable requirements related to information security;
|
||||
e) commitment to continual improvement of the information security management system;
|
||||
f) assignment of responsibilities for information security management to defined roles;
|
||||
g) procedures for handling exemptions and exceptions.
|
||||
|
||||
Top management should approve any changes to the information security policy.
|
||||
|
||||
At a lower level, the information security policy should be supported by topic-specific policies as needed, to further mandate the implementation of information security controls. Topic-specific policies are typically structured to address the needs of certain target groups within an organization or to cover certain security areas. Topic-specific policies should be aligned with and complementary to the information security policy of the organization.
|
||||
|
||||
Examples of such topics include:
|
||||
|
||||
a) access control;
|
||||
b) physical and environmental security;
|
||||
c) asset management;
|
||||
d) information transfer;
|
||||
e) secure configuration and handling of user endpoint devices;
|
||||
f) networking security;
|
||||
g) information security incident management;
|
||||
h) backup;
|
||||
i) cryptography and key management;
|
||||
j) information classification and handling;
|
||||
k) management of technical vulnerabilities;
|
||||
l) secure development.
|
||||
|
||||
The responsibility for the development, review and approval of the topic-specific policies should be allocated to relevant personnel based on their appropriate level of authority and technical competency. The review should include assessing opportunities for improvement of the organization’s information security policy and topic-specific policies and managing information security in response to changes to:
|
||||
|
||||
a) the organization’s business strategy;
|
||||
b) the organization’s technical environment;
|
||||
c) regulations, statutes, legislation and contracts;
|
||||
d) information security risks;
|
||||
e) the current and projected information security threat environment;
|
||||
f) lessons learned from information security events and incidents.
|
||||
|
||||
The review of information security policy and topic-specific policies should take the results of management reviews and audits into account. Review and update of other related policies should be considered when one policy is changed to maintain consistency.
|
||||
|
||||
The information security policy and topic-specific policies should be communicated to relevant personnel and interested parties in a form that is relevant, accessible and understandable to the intended reader. Recipients of the policies should be required to acknowledge they understand and agree to comply with the policies where applicable. The organization can determine the formats and names of these policy documents that meet the organization’s needs. In some organizations, the information security policy and topic-specific policies can be in a single document. The organization can name these topic-specific policies as standards, directives, policies or others.
|
||||
|
||||
If the information security policy or any topic-specific policy is distributed outside the organization, care should be taken not to improperly disclose confidential information.
|
||||
|
||||
Table 1 illustrates the differences between information security policy and topic-specific policy.
|
||||
|
||||
*Table 1* | Information security policy | Topic-specific policy
|
||||
------- | --------------------------- | ---------------------
|
||||
Level of detail | General or high-level | Specific and detailed
|
||||
Documented and formally approved by | Top management | Appropriate level of management
|
||||
|
||||
#### Other information
|
||||
Topic-specific policies can vary across organizations.
|
||||
|
||||
|
||||
# Related
|
||||
- [[ISO_27002_PE 5.1 Policies for information security]]
|
||||
|
||||
|
|
@ -1,57 +0,0 @@
|
|||
#iso27002/2022/EN
|
||||
|
||||
# 5.22 Monitoring, review and change management of supplier services
|
||||
|
||||
**Control**
|
||||
The organization should regularly monitor, review, evaluate and manage change in supplier information security practices and service delivery.
|
||||
|
||||
**Purpose**
|
||||
To maintain an agreed level of information security and service delivery in line with supplier agreements.
|
||||
|
||||
**Guidance**
|
||||
Monitoring, review and change management of supplier services should ensure the information security terms and conditions of the agreements are complied with, information security incidents and problems are managed properly and changes in supplier services or business status do not affect service delivery.
|
||||
|
||||
This should involve a process to manage the relationship between the organization and the supplier to:
|
||||
|
||||
a\) monitor service performance levels to verify compliance with the agreements;
|
||||
|
||||
b) monitor changes made by suppliers including:
|
||||
1) enhancements to the current services offered;
|
||||
2) development of any new applications and systems;
|
||||
3) modifications or updates of the supplier’s policies and procedures;
|
||||
4) new or changed controls to resolve information security incidents and to improve information security;
|
||||
|
||||
c) monitor changes in supplier services including:
|
||||
1) changes and enhancement to networks;
|
||||
2) use of new technologies;
|
||||
3) adoption of new products or newer versions or releases;
|
||||
4) new development tools and environments;
|
||||
5) changes to physical location of service facilities;
|
||||
6) change of sub-suppliers;
|
||||
7) sub-contracting to another supplier;
|
||||
|
||||
d\) review service reports produced by the supplier and arrange regular progress meetings as required by the agreements;
|
||||
|
||||
e\) conduct audits of suppliers and sub-suppliers, in conjunction with review of independent auditor’s reports, if available and follow-up on issues identified;
|
||||
|
||||
f\) provide information about information security incidents and review this information as required by the agreements and any supporting guidelines and procedures;
|
||||
|
||||
g\) review supplier audit trails and records of information security events, operational problems, failures, tracing of faults and disruptions related to the service delivered;
|
||||
|
||||
h\) respond to and manage any identified information security events or incidents;
|
||||
|
||||
i\) identify information security vulnerabilities and manage them;
|
||||
|
||||
j\) review information security aspects of the supplier’s relationships with its own suppliers;
|
||||
|
||||
k\) ensure that the supplier maintains sufficient service capability together with workable plans designed to ensure that agreed service continuity levels are maintained following major service failures or disaster (see [[5.29]], [[5.30]], [[5.35]], [[5.36]], [[8.14]];
|
||||
|
||||
l\) ensure that suppliers assign responsibilities for reviewing compliance and enforcing the requirements of the agreements;
|
||||
|
||||
m\) evaluate regularly that the suppliers maintain adequate information security levels.
|
||||
|
||||
|
||||
The responsibility for managing supplier relationships should be assigned to a designated individual or team. Sufficient technical skills and resources should be made available to monitor that the requirements of the agreement, in particular the information security requirements, are being met. Appropriate actions should be taken when deficiencies in the service delivery are observed.
|
||||
|
||||
**Other information**
|
||||
See ISO/IEC 27036-3 for more detail.
|
||||
|
|
@ -1,53 +0,0 @@
|
|||
#iso27002/2022/EN
|
||||
## 5.23 Information security for use of cloud services
|
||||
|
||||
#### Control
|
||||
Processes for acquisition, use, management and exit from cloud services should be established in accordance with the organization’s information security requirements.
|
||||
#### Purpose
|
||||
To specify and manage information security for the use of cloud services.
|
||||
#### Guidance
|
||||
The organization should establish and communicate topic-specific policy on the use of cloud services to all relevant interested parties.
|
||||
|
||||
The organization should define and communicate how it intends to manage information security risks associated with the use of cloud services. It can be an extension or part of the existing approach for how an organization manages services provided by external parties (see 5.21 and 5.22).
|
||||
|
||||
The use of cloud services can involve shared responsibility for information security and collaborative effort between the cloud service provider and the organization acting as the cloud service customer. It is essential that the responsibilities for both the cloud service provider and the organization, acting as the cloud service customer, are defined and implemented appropriately.
|
||||
|
||||
The organization should define:
|
||||
a) all relevant information security requirements associated with the use of the cloud services;
|
||||
b) cloud service selection criteria and scope of cloud service usage;
|
||||
c) roles and responsibilities related to the use and management of cloud services;
|
||||
d) which information security controls are managed by the cloud service provider and which are managed by the organization as the cloud service customer;
|
||||
e) how to obtain and utilize information security capabilities provided by the cloud service provider;
|
||||
f) how to obtain assurance on information security controls implemented by cloud service providers;
|
||||
g) how to manage controls, interfaces and changes in services when an organization uses multiple cloud services, particularly from different cloud service providers;
|
||||
h) procedures for handling information security incidents that occur in relation to the use of cloud services;
|
||||
i) its approach for monitoring, reviewing and evaluating the ongoing use of cloud services to manage information security risks;
|
||||
j) how to change or stop the use of cloud services including exit strategies for cloud services.
|
||||
|
||||
Cloud service agreements are often pre-defined and not open to negotiation. For all cloud services, the organization should review cloud service agreements with the cloud service provider(s). A cloud service agreement should address the confidentiality, integrity, availability and information handling requirements of the organization, with appropriate cloud service level objectives and cloud service qualitative objectives. The organization should also undertake relevant risk assessments to identify the risks associated with using the cloud service. Any residual risks connected to the use of the cloud service should be clearly identified and accepted by the appropriate management of the organization.
|
||||
|
||||
An agreement between the cloud service provider and the organization, acting as the cloud service customer, should include the following provisions for the protection of the organization’s data and availability of services:
|
||||
a) providing solutions based on industry accepted standards for architecture and infrastructure;
|
||||
b) managing access controls of the cloud service to meet the requirements of the organization;
|
||||
c) implementing malware monitoring and protection solutions;
|
||||
d) processing and storing the organization’s sensitive information in approved locations (e.g. particular country or region) or within or subject to a particular jurisdiction;
|
||||
e) providing dedicated support in the event of an information security incident in the cloud service environment;
|
||||
f) ensuring that the organization’s information security requirements are met in the event of cloud services being further sub-contracted to an external supplier (or prohibiting cloud services from being sub-contracted);
|
||||
g) supporting the organization in gathering digital evidence, taking into consideration laws and regulations for digital evidence across different jurisdictions;
|
||||
h) providing appropriate support and availability of services for an appropriate time frame when the organization wants to exit from the cloud service;
|
||||
i) providing required backup of data and configuration information and securely managing backups as applicable, based on the capabilities of the cloud service provider used by the organization, acting as the cloud service customer;
|
||||
j) providing and returning information such as configuration files, source code and data that are owned by the organization, acting as the cloud service customer, when requested during the service provision or at termination of service.
|
||||
|
||||
The organization, acting as the cloud service customer, should consider whether the agreement should require cloud service providers to provide advance notification prior to any substantive customer impacting changes being made to the way the service is delivered to the organization, including:
|
||||
a) changes to the technical infrastructure (e.g. relocation, reconfiguration, or changes in hardware or software) that affect or change the cloud service offering;
|
||||
b) processing or storing information in a new geographical or legal jurisdiction;
|
||||
c) use of peer cloud service providers or other sub-contractors (including changing existing or using new parties).
|
||||
|
||||
The organization using cloud services should maintain close contact with its cloud service providers. These contacts enable mutual exchange of information about information security for the use of the cloud services including a mechanism for both cloud service provider and the organization, acting as the cloud service customer, to monitor each service characteristic and report failures to the commitments contained in the agreements.
|
||||
|
||||
#### Other information
|
||||
This control considers cloud security from the perspective of the cloud service customer.
|
||||
|
||||
Additional information relating to cloud services can be found in ISO/IEC 17788, ISO/IEC 17789 and ISO/IEC 22123-1. Specifics related to cloud portability in support of exit strategies can be found in ISO/IEC 19941. Specifics related to information security and public cloud services are described in ISO/IEC 27017. Specifics related to PII protection in public clouds acting as PII processor are described in ISO/IEC 27018. Supplier relationships for cloud services are covered by ISO/IEC 27036-4 and cloud service agreements and their contents are dealt with in the ISO/IEC 19086 series, with security and privacy specifically covered by ISO/IEC 19086-4.
|
||||
# Related:
|
||||
- [[ISO_27002_PE 5.23 Information security for use of cloud services]]
|
||||
|
|
@ -1,66 +0,0 @@
|
|||
#iso27002/2022/EN
|
||||
## 5.24 Information security incident management planning and preparation
|
||||
|
||||
#### Control
|
||||
The organization should plan and prepare for managing information security incidents by defining, establishing and communicating information security incident management processes, roles and responsibilities.
|
||||
#### Purpose
|
||||
To ensure quick, effective, consistent and orderly response to information security incidents, including communication on information security events.
|
||||
#### Guidance
|
||||
|
||||
**Roles and responsibilities**
|
||||
|
||||
The organization should establish appropriate information security incident management processes. Roles and responsibilities to carry out the incident management procedures should be determined and effectively communicated to the relevant internal and external interested parties.
|
||||
|
||||
The following should be considered:
|
||||
|
||||
a\) establishing a common method for reporting information security events including point of contact (see [[ISO_27002_OT n.n Title\|6.8]]);
|
||||
|
||||
b\) establishing an incident management process to provide the organization with capability for managing information security incidents including administration, documentation, detection, triage, prioritization, analysis, communication and coordinating interested parties;
|
||||
|
||||
c\) establishing an incident response process to provide the organization with capability for assessing, responding to and learning from information security incidents;
|
||||
|
||||
d\) only allowing competent personnel to handle the issues related to information security incidents within the organization. Such personnel should be provided with procedure documentation and periodic training;
|
||||
|
||||
e\) establishing a process to identify required training, certification and ongoing professional development for incident response personnel.
|
||||
|
||||
**Incident management procedures**
|
||||
|
||||
The objectives for information security incident management should be agreed with management and it should be ensured that those responsible for information security incident management understand the organization’s priorities for handling information security incidents, including resolution time frame based on potential consequences and severity. Incident management procedures should be implemented to meet these objectives and priorities.
|
||||
|
||||
Management should ensure that an information security incident management plan is created considering different scenarios and procedures are developed and implemented for the following activities:
|
||||
|
||||
a\) evaluation of information security events according to criteria for what constitutes an information security incident;
|
||||
|
||||
b\) monitoring (see [[ISO_27002_OT n.n Title\|8.15]] and [[ISO_27002_OT n.n Title\|8.16]]), detecting (see [[ISO_27002_OT n.n Title\|8.16]]), classifying (see [[ISO_27002_OT n.n Title\|5.25]]), analysing and reporting (see [[ISO_27002_OT n.n Title\|6.8]]) of information security events and incidents (by human or automatic means);
|
||||
|
||||
c\) managing information security incidents to conclusion, including response and escalation (see [[ISO_27002_OT n.n Title\|5.26]]), according to the type and the category of the incident, possible activation of crisis management and activation of continuity plans, controlled recovery from an incident and communication to internal and external interested parties;
|
||||
|
||||
d\) coordination with internal and external interested parties such as authorities, external interest groups and forums, suppliers and clients (see [[ISO_27002_OT 5.5 Contact with authorities|5.5]] and [[ISO_27002_OT 5.6 Contact with special interest groups\|5.6]]);
|
||||
|
||||
e\) logging incident management activities;
|
||||
|
||||
f\) handling of evidence (see [[ISO_27002_OT n.n Title\|5.28]]);
|
||||
|
||||
g\) root cause analysis or post-mortem procedures;
|
||||
|
||||
h\) identification of lessons learned and any improvements to the incident management procedures or information security controls in general that are required.
|
||||
|
||||
**Reporting procedures**
|
||||
|
||||
Reporting procedures should include:
|
||||
|
||||
a\) actions to be taken in case of an information security event (e.g. noting all pertinent details immediately such as malfunction occurring and messages on screen, immediately reporting to the point of contact and only taking coordinated actions);
|
||||
|
||||
b\) use of incident forms to support personnel to perform all necessary actions when reporting information security incidents;
|
||||
|
||||
c\) suitable feedback processes to ensure that those persons reporting information security events are notified, to the extent possible, of outcomes after the issue has been addressed and closed;
|
||||
|
||||
d\) creation of incident reports.
|
||||
|
||||
Any external requirements on reporting of incidents to relevant interested parties within the defined time frame (e.g. breach notification requirements to regulators) should be considered when implementing incident management procedures.
|
||||
|
||||
**Other information**
|
||||
|
||||
Information security incidents can transcend organizational and national boundaries. To respond to such incidents, it is beneficial to coordinate response and share information about these incidents with external organizations as appropriate.
|
||||
|
||||
Detailed guidance on information security incident management is provided in the ISO/IEC 27035 series.
|
||||
|
|
@ -1,20 +0,0 @@
|
|||
#iso27002/2022/EN
|
||||
## 5.27 Learning from information security incidents
|
||||
|
||||
#### Control
|
||||
Knowledge gained from information security incidents should be used to strengthen and improve the information security controls.
|
||||
#### Purpose
|
||||
To reduce the likelihood or consequences of future incidents.
|
||||
#### Guidance
|
||||
The organization should establish procedures to quantify and monitor the types, volumes and costs of information security incidents.
|
||||
|
||||
The information gained from the evaluation of information security incidents should be used to:
|
||||
|
||||
a\) enhance the incident management plan including incident scenarios and procedures (see [[ISO_27002_OT 5.24 Information security incident management planning and preparation|5.24]]);
|
||||
|
||||
b\) identify recurring or serious incidents and their causes to update the organization’s information security risk assessment and determine and implement necessary additional controls to reduce the likelihood or consequences of future similar incidents. Mechanisms to enable that include collecting, quantifying and monitoring information about incident types, volumes and costs;
|
||||
|
||||
c\) enhance user awareness and training (see [[ISO_27002_OT 6.3 Information security awareness, education and training|6.3]]) by providing examples of what can happen, how to respond to such incidents and how to avoid them in the future.
|
||||
#### Other information
|
||||
|
||||
The ISO/IEC 27035 series provides further guidance.
|
||||
|
|
@ -1,42 +0,0 @@
|
|||
#iso27002/2022/EN
|
||||
# **5.30** **ICT** **readiness** **for** **business** continuity
|
||||
|
||||
## Purpose
|
||||
To ensure the availability of the organization’s information and other associated assets during disruption.
|
||||
## Guidance
|
||||
ICT readiness for business continuity is an important component in business continuity management and information security management to ensure that the organization’s objectives can continue to be met during disruption.
|
||||
|
||||
The ICT continuity requirements are the outcome of the business impact analysis (BIA). The BIA process should use impact types and criteria to assess the impacts over time resulting from the disruption of business activities that deliver products and services. The magnitude and duration of the resulting impact should be used to identify prioritized activities which should be assigned a recovery time objective (RTO). The BIA should then determine which resources are needed to support prioritized activities. An RTO should also be specified for these resources. A subset of these resources should include ICT services.
|
||||
|
||||
The BIA involving ICT services can be expanded to define performance and capacity requirements of ICT systems and recovery point objectives (RPO) of information required to support activities during disruption.
|
||||
|
||||
Based on the outputs from the BIA and risk assessment involving ICT services, the organization should identify and select ICT continuity strategies that consider options for before, during and after disruption. The business continuity strategies can comprise one or more solutions. Based on the strategies, plans should be developed, implemented and tested to meet the required availability level of ICT services and in the required time frames following interruption to, or failure of, critical processes.
|
||||
|
||||
The organization should ensure that:
|
||||
|
||||
a) an adequate organizational structure is in place to prepare for, mitigate and respond to a disruption supported by personnel with the necessary responsibility, authority and competence;
|
||||
|
||||
b) ICT continuity plans, including response and recovery procedures detailing how the organization is planning to manage an ICT service disruption, are:
|
||||
|
||||
1) regularly evaluated through exercises and tests;
|
||||
2) approved by management;
|
||||
|
||||
c) ICT continuity plans include the following ICT continuity information:
|
||||
|
||||
1) performance and capacity specifications to meet the business continuity requirements and objectives as specified in the BIA;
|
||||
2) RTO of each prioritized ICT service and the procedures for restoring those components;
|
||||
3) RPO of the prioritized ICT resources defined as information and the procedures for restoring the information.
|
||||
|
||||
## Other **information**
|
||||
|
||||
Managing ICT continuity forms a key part of business continuity requirements concerning availability to be able to:
|
||||
|
||||
a) respond and recover from disruption to ICT services regardless of the cause;
|
||||
|
||||
b) ensure continuity of prioritized activities are supported by the required ICT services;
|
||||
|
||||
c) respond before a disruption to ICT services occurs, and upon detection of at least one incident that can result in a disruption to ICT services.
|
||||
|
||||
Further guidance on ICT readiness for business continuity can be found in ISO/IEC 27031.
|
||||
|
||||
Further guidance on business continuity management systems can be found in ISO 22301 and ISO 22313. Further guidance on BIA can be found in ISO/TS 22317.
|
||||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Add table
Add a link
Reference in a new issue