• No results found

Objective To document and agree the integrity requirements (the need for information to be valid, accurate and complete) for information associated with target environments (eg critical business

environments, business processes, business applications (including those under development) or computer systems).

SR1.4.1

Business requirements should take account of the need to protect the integrity of information.

SR1.4.2

The analysis of integrity requirements should determine how the accidental corruption or deliberate manipulation of information could have a fi nancial impact on the organisation in terms of:

a) loss of sales, orders or contracts (eg sales opportunities missed, orders not taken or contracts not signed) b) loss of tangible assets (eg through fraud, theft of money or lost interest)

c) penalties / legal liabilities (eg through breach of legal, regulatory or contractual obligations) d) unforeseen costs (eg recovery costs, uninsured losses, increased insurance)

e) depressed share price (eg sudden or prolonged loss of share value, or random share value fl uctuation).

SR1.4.3

The analysis of integrity requirements should determine how the accidental corruption or deliberate manipulation of information could have an operational impact on the organisation in terms of:

a) loss of management control (eg impaired decision-making, inability to monitor fi nancial positions, or process management failure)

b) loss of competitiveness (eg repetitive production line failures, degraded customer service or introduction of new pricing policies)

c) new ventures held up (eg delayed new products, delayed entry into new markets or delayed mergers / acquisitions)

d) breach of operating standards (eg contravention of regulatory, quality or safety standards).

SR1.4.4

The analysis of integrity requirements should determine how the accidental corruption or deliberate manipulation of information could have a customer-related impact on the organisation in terms of:

a) delayed deliveries to customers or clients (eg failure to meet product delivery deadlines or failure to complete contracts on time)

b) loss of customers or clients (eg customer / client defection to competitors or withdrawal of preferred supplier status by customer / client)

c) loss of confi dence by key institutions (eg adverse criticism by investors, regulators, customers or suppliers) d) damage to reputation (eg confi dential fi nancial information published in media, compromising internal

memos broadcast by media).

SR1.4.5

The analysis of integrity requirements should determine how the accidental corruption or deliberate manipulation of information could have an employee-related impact on the organisation in terms of:

a) reduction in staff morale / productivity (eg reduced effi ciency, lost time or job losses) b) injury or death.

SECURITY REQUIREMENTS

www.securityforum.org

FUNDAMENTAL

SR

SR1.4 2011 Standard of Good Practice • Copyright © 2011 Information Security Forum

SR1.4 Integrity Requirements

(continued)

Related areas / topics

SR1.6 Information Risk Treatment SI2.2 Information Risk Reporting

ISF resources

SECURITY REQUIREMENTS

www.securityforum.org

FUNDAMENTAL

SR

Copyright © 2011 Information Security Forum • 2011 Standard of Good Practice SR1.5

SR1.5 Availability Requirements

Principle

The business impact of business information associated with target environments being unavailable

for any length of time should be assessed.

Objective

To document and agree the availability requirements (the need for information to be accessible

when required) for information associated with target environments (eg critical business environments, business processes, business applications (including those under development) or computer systems).

SR1.5.1

Business requirements should take account of the need to protect the availability of information.

SR1.5.2

The analysis of availability requirements should determine how a loss of availability of information could have a fi nancial impact on the organisation in terms of:

a) loss of sales, orders or contracts (eg sales opportunities missed, orders not taken or contracts not signed) b) loss of tangible assets (eg through fraud, theft of money or lost interest)

c) penalties / legal liabilities (eg through breach of legal, regulatory or contractual obligations) d) unforeseen costs (eg recovery costs, uninsured losses, increased insurance)

e) depressed share price (eg sudden or prolonged loss of share value, or random share value fl uctuation).

SR1.5.3

The analysis of availability requirements should determine how a loss of availability of information could have an operational impact on the organisation in terms of:

a) loss of management control (eg impaired decision-making, inability to monitor fi nancial positions, or process management failure)

b) loss of competitiveness (eg repetitive production line failures, degraded customer service or introduction of new pricing policies)

c) new ventures held up (eg delayed new products, delayed entry into new markets or delayed mergers / acquisitions)

d) breach of operating standards (eg contravention of regulatory, quality or safety standards).

SR1.5.4

The analysis of availability requirements should determine how a loss of availability of information could have a customer-related impact on the organisation in terms of:

a) delayed deliveries to customers or clients (eg failure to meet product delivery deadlines or failure to complete contracts on time)

b) loss of customers or clients (eg customer / client defection to competitors or withdrawal of preferred supplier status by customer / client)

c) loss of confi dence by key institutions (eg adverse criticism by investors, regulators, customers or suppliers) d) damage to reputation (eg confi dential fi nancial information published in media, compromising internal

memos broadcast by media).

SR1.5.5

The analysis of availability requirements should determine how a loss of availability of information could have an employee-related impact on the organisation in terms of:

a) reduction in staff morale / productivity (eg reduced effi ciency, lost time or job losses) b) injury or death.

SECURITY REQUIREMENTS

www.securityforum.org

FUNDAMENTAL

SR

SR1.5 2011 Standard of Good Practice • Copyright © 2011 Information Security Forum

SR1.5 Availability Requirements

(continued)

SR1.5.6

Business requirements should take into account the critical timescale of the application (ie the timescale beyond which an outage is unacceptable to the organisation).

Related areas / topics

SR1.6 Information Risk Treatment SI2.2 Information Risk Reporting

ISF resources

SECURITY REQUIREMENTS

www.securityforum.org

FUNDAMENTAL

SR

Copyright © 2011 Information Security Forum • 2011 Standard of Good Practice SR1.6

SR1.6

Information Risk Treatment

Principle

Information risks should be treated in accordance with business requirements and the approach

taken approved by the relevant business owner.

Objective

To help ensure information risks are treated (eg accepted, avoided, transferred or mitigated) in a

suitable manner.

SR1.6.1

Risks identifi ed as part of an information risk assessment should be treated according to the organisation’s security requirements (risk appetite), taking into account business circumstances and level of threat – and approved by executive management.

SR1.6.2

Options to treat information risk (risk treatment) should include:

a) accepting risks (eg business owners take responsibility for accepting the business consequences and signing off the risks)

b) avoiding risks (eg by cancelling a high risk project or deciding not to pursue a particular business initiative) c) transferring risks (eg by sharing the risks with an external party or by taking out insurance)

d) mitigating the risk, typically by applying appropriate security controls (eg malware protection, digital rights management or data leakage protection (DLP)).

SR1.6.3

Accepting information risks (ie the business owner takes responsibility for accepting the business consequences) should include:

a) consideration of predefi ned limits for levels of risk (eg quantitative values such as fi nancial thresholds or qualitative values such as a ratings scale of very low to very high)

b) approval and sign-off by a senior individual with authority, such as a representative of executive management (eg senior executive or equivalent)

c) acknowledging that risk is still present and management will accept the consequences if incidents occur d) recording them in a central register (where they can be reviewed and compared with other risks and related

treatment decisions).

SR1.6.4

Avoiding information risks should involve a decision by a senior individual to cancel or postpone a particular project or initiative that introduces the risk (eg adopting a particular technology, allowing external access, offering products in a new market (jurisdiction) or providing a new service to customers).

SR1.6.5

Transferring information risks should involve:

a) sharing the risks with external parties such as joint venture partners, outsource providers or cloud service providers (eg sharing fi nancial investment and resources)

SECURITY REQUIREMENTS

www.securityforum.org

FUNDAMENTAL

SR

SR1.6 2011 Standard of Good Practice • Copyright © 2011 Information Security Forum

SR1.6

Information Risk Treatment

(continued)

SR1.6.6

Applying security controls to mitigate information risk should include: a) applying (or mapping to) a reputable security control framework b) evaluating the strengths and weaknesses of security controls

c) selecting security controls that will reduce the likelihood of serious information security incidents occurring – and reducing their impact if they do occur

d) selecting security controls that will satisfy relevant compliance requirements (eg those outlined in the Sarbanes- Oxley Act, legislation associated with EU Directives 2006/43/EC and 2006/46/EC, the Payment Card Industry Data Security Standard (PCI DSS), Basel III, data privacy requirements and anti-money laundering requirements) e) assessing the costs of implementing security controls (eg costs associated with: design, purchase,

implementation and monitoring of the controls; hardware and software; training; overheads, such as facilities; and consultancy fees)

f) identifying specialised security controls required by particular environments (eg data encryption or strong authentication)

g) identifying and obtaining sign-off for any residual risk (ie the proportion of risk that still remains after selected controls have been implemented).

SR1.6.7

Information risk treatment actions (including any residual risk) should be detailed in a risk treatment plan, which is:

a) communicated to the relevant owner

b) signed off by the relevant owner and at least one representative of top-level management (eg senior executive or equivalent)

c) compared with information risk assessments conducted in other areas of the organisation.

Related areas / topics

SR1.1 Managing Information Risk Assessment

SR1.2 Information Risk Assessment Methodologies

SI2.2 Information Risk Reporting

ISF resources

SECURITY REQUIREMENTS

www.securityforum.org

FUNDAMENTAL

SR

Copyright © 2011 Information Security Forum • 2011 Standard of Good Practice SR2.1

SR2.1

Legal and Regulatory Compliance

Principle

A process should be established to identify and interpret the information security implications of

relevant laws and regulations.

Objective

To comply with laws and regulations affecting information security.

SR2.1.1

Legal and regulatory requirements affecting information security should be recognised by: a) executive management

b) business owners

c) the head of information security (or equivalent)

d) representatives of other security-related functions (eg legal, operational risk, internal audit, insurance, human resources, and physical security).

SR2.1.2

A process should be established for ensuring compliance with relevant legal and regulatory requirements affecting information security across the organisation, which covers:

a) information security-specifi c legislation (eg computer crimes, encryption export, data breach notifi cation and e-discovery)

b) general legislation which has security implications (eg data privacy, investigatory powers, intellectual property and human rights)

c) regulation (eg fi nancial regulation, anti-money laundering, corporate governance, healthcare and industry specifi c regulations such as the Payment Card Industry Data Security Standard (PCI DSS)).

SR2.1.3

The compliance process should enable decision-makers to:

a) discover laws and regulations that affect information security (eg by using the services of law fi rms and industry watchdog groups that provide updates on new regulations, changes to existing regulations and results of litigation (case law or precedent))

b) interpret the information security implications of these laws and regulations

c) identify potential legal / regulatory non-compliance (eg performing a risk assessment of compliance with laws and regulations)

d) address areas of potential legal / regulatory non-compliance.

SR2.1.4

The compliance process should be documented, signed off by executive management, and kept up-to-date.

AREA SR2 – Compliance

Outline

Related documents