Hacking For Dummies
Book image
Explore Book Buy On Amazon
Integrating security risk considerations into acquisition strategy and practice helps to minimize the introduction of new or unknown risks into the organization. It is often said that security in an organization is only as strong as its weakest link. In the context of mergers and acquisitions, often one of the organizations will be more secure than the other. Connecting two organizations together before sufficient analysis can result in significant impairment of the security capabilities of the new organization.

The task of reconciling policies, requirements, business processes, and procedures during a merger or acquisition is rarely straightforward. Further, there should be no assumption of one organization's policies, requirements, processes and procedures being the "right" or "best" way for all parties in the merger or acquisition — even if that organization is the acquiring entity.

Instead, each organization's individual policies, requirements, processes and procedures should be assessed to identify the best solution for the new formed organization going forward.

Hardware, software, and services

Any new hardware, software, or services being considered by an organization should be appropriately evaluated to determine both how it will impact the organization's overall security and risk posture, and how it will affect other hardware, software, or services already in place within the organization. For example, integration issues can have a negative impact on a system's integrity and availability.

Third-party assessment and monitoring

In a merger or acquisition, it's important to consider the third parties that each organization brings to the table. Not only do the acquiring or merging organizations need to carefully examine their third party risk programs, but also a fresh look at the third parties themselves is needed, to ensure that the risk level related to each third party has not changed in light of the merger or acquisition.

Any new third-party assessments or monitoring should be carefully considered. Contracts (including privacy, non-disclosure requirements, and security requirements) and service-level agreements (SLAs, discussed later in this section) should be reviewed to ensure that all important security issues and regulatory requirements still are addressed adequately.

Minimum security requirements

Minimum security requirements, standards and baselines should be documented to ensure they are fully understood and considered in acquisition strategy and practice. Blending security requirements from two previously separate organizations is almost never as easy as simply combining them together into one document. Instead, there may be many instances of overlap, underlap, and contradiction that must all be reconciled. A transition period may be required, so that there is ample time to adjust the security configurations and architectures to meet the new set of requirements after the merger or acquisition.

Service-level requirements

Service-level agreements (SLAs) establish minimum performance standards for a system, application, network, or service. An organization establishes internal SLAs to provide its end-users with a realistic expectation of the performance of its information systems and services. For example, a help desk SLA might prioritize incidents as 1, 2, 3, and 4, and establish SLA response times of ten minutes, 1 hour, 4 hours, and 24 hours, respectively. In third-party relationships, SLAs provide contractual performance requirements that an outsourcing partner or vendor must meet. For example, an SLA with an Internet service provider might establish a maximum acceptable downtime which, if exceeded within a given period, results in invoice credits or (if desired) cancellation of the service contract.

About This Article

This article can be found in the category: