CISSP For Dummies
Book image
Explore Book Buy On Amazon
Integrating security risk considerations into supply chain management and merger and acquisition strategy 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 service providers, mergers, and acquisitions, the security of all organizations in a given ecosystem will be dragged down by shoddy practices in any one of them. Connecting organizations together before sufficient analysis can result in significant impairment of the security capabilities overall.

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, services, and processes 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

It’s important to consider the third parties that organizations use. Not only do organizations need to carefully examine their third-party risk programs, but also a fresh look of third parties themselves is needed, to ensure that the risk level related to each third party has not changed to the detriment of the organization.

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, gaps, and contradiction that must all be reconciled. A transition period may be required, so that there is ample time to adjust the security configurations, architectures, processes, and practices 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, service, or process. An organization establishes internal SLAs and operating level agreements (OLAs) to provide its end-users with a realistic expectation of the performance of its information systems, services, and processes. 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 is from the book:

About the book authors:

Lawrence C. Miller, CISSP, is a veteran information security professional. He has served as a consultant for multinational corporations and holds many networking certifications.

Peter H. Gregory, CISSP, is a security, risk, and technology director with experience in SAAS, retail, telecommunications, non-profit, manufacturing, healthcare, and beyond. Larry and Peter have been coauthors of CISSP For Dummies for more than 20 years.

Lawrence C. Miller, CISSP, is a veteran information security professional. He has served as a consultant for multinational corporations and holds many networking certifications.

Peter H. Gregory, CISSP, is a security, risk, and technology director with experience in SAAS, retail, telecommunications, non-profit, manufacturing, healthcare, and beyond. Larry and Peter have been coauthors of CISSP For Dummies for more than 20 years.

This article can be found in the category: