LII:Choosing and Implementing a Cloud-based Service for Your Laboratory/Managed security services and quality assurance

From LIMSWiki
Jump to navigationJump to search
-----Return to the beginning of this guide-----

5. Managed security services and quality assurance

So far in this guide, the assumption has been made that your organization—whether a laboratory or some other business type—will either have the knowledgeable and experienced onsite personnel to assist with a cloud implementation or will acquire such people as new hires or contracted consultants. But as the age of cloud computing has progressed ever onward and more businesses have moved to the cloud, a third option has emerged: have someone else, like an MSSP, manage most of the implementation and security details for you.

5.1 The provision of managed security services

Gartner defines a managed security service provider (MSSP) as an entity that "provides outsourced monitoring and management of security devices and systems," including "managed firewall, intrusion detection, virtual private network, vulnerability scanning, and anti-viral services."[1] Gartner continues, noting that MSSPs run their security operations through their own or third-party data centers in order to provide an "always available" service, with the ultimate intent of reducing "the number of operational security personnel an enterprise needs to hire, train, and retain to maintain an acceptable security posture."[1] In addition to reducing personnel requirements, turning to an MSSP may also improve the overall security competency of and reduce the technological complexity burdens within an organization.[2][3]

One perceived downside to this approach may be the added risk of placing access to sensitive data in the hands of a third party, and indeed, there may be a few unique situations where it makes the most sense to keep security operations in-house.[4] However, this perceived downside largely comes down to a question of the trust you place in the MSSP. As was discussed in previous chapters, many cloud service providers (CSPs) recognize the importance of supporting the element of trust associated with its services, as witnessed by their trust centers and associated documentation and certifications, particularly those related to the management of sensitive data. This element of trust is also baked into the service level agreement (SLA) provided by the CSP.[4] In the end, just like a CSP, the level of trust you place with an MSSP will largely be based upon your business' approach to both vetting them and determining the level of accepted risk should the MSSP not be able to meet your every requirement. (These aspects are discussed in further detail in the following chapter.)

5.1.1 Managed security services in the cloud


Just as turning to a CSP's infrastructure as a service (IaaS) offloads much of the responsibility for supporting IT infrastructure to someone else, you can also offload a significant portion of the responsibility for supporting cloud security to someone else. As such, the vendor of managed security services (MSS)—whether it's the CSP itself or a third-party cloud-friendly MSSP—manages cloud-based security aspects such as vulnerability testing, intrusion detection, firewall management, virtual private network (VPN) management, security reporting, and technical support for your cloud implementation. As such, most of your internal IT staff can be freed to focus on other aspects of the business' IT infrastructure and operational developments.

But turning to MSS for your cloud implementation should be about more than just staffing relief. Outsourcing security services may also have other perceived benefits to an organization, such as gaining operational and financial efficiency, increasing service availability, and avoiding technological obsolescence.[5] To be sure, managing cybersecurity in the cloud is both vital to and difficult for the average organization, particularly small organizations like independent laboratories with constrained budgets. Managing the physical and cybersecurity complexities associated with the likes of the Health Insurance Portability and Accountability Act (HIPAA), the General Data Protection Regulation (GDPR), and the Payment Card Industry Data Security Standard (PCI DSS) can be daunting, particularly given a lack of sufficient in-house expertise. Throw hybrid and multicloud deployments into the mix, and you suddenly require even more in-house expertise for development in public cloud environments like AWS and Microsoft Azure. When also considering that traditional on-premises IT security experience is not enough to manage cloud implementations, it's not difficult to imagine a scenario where an inexperienced IT staff could misconfigure a network security setting and compromise sensitive data within a cloud implementation.[4]

An optimally run set of managed security services by a knowledgeable and experienced organization able to offer and stick to clear, legally defensible service level agreements and information governance mechanisms[6][7] makes sense for organizations without the necessary technical expertise and with significant liability should something go wrong. The complexities of running secure operations in the cloud only increase the importance of such an MSSP. Such a provider is able to[8]:

  • monitor for, identify, assess, and react to vulnerabilities, intrusions, and other threats;
  • audit, adjust, and patch native security settings;
  • improve encryption, firewall, and anti-malware mechanisms;
  • manage and secure connected devices;
  • manage and improve identity access management; and
  • provide detailed reports about the state of organizational infrastructure.

5.2 Managed security services and the laboratory

The previous chapter explored many aspects of informatics in the laboratory, emphasizing that while software and hardware systems bring many benefits to the laboratory, a thoughtful, organization-wide approach to managing the risks that that software and hardware introduces—particularly when related to cloud computing—is required. Given these complications, it's unsurprising to learn some laboratories have turned to MSSPs to help them meet regulatory requirements and maintain the security of their on-premises and cloud-based data solutions. Examples of industries with research and laboratory work served by MSSPs over the years include the gemstone testing and grading[9], energy research and supply[10], clinical and forensic toxicology[11], and healthcare industries.[12][13] In all these examples, the implication is that proprietary trade secrets, critical infrastructure, or sensitive patient data must be protected. The laboratories operating in those industries could have attempted to keep security efforts in-house, but for one reason or another they chose to outsource a significant portion of that protection to a third-party MSSP.

But why even bother with this level of security? As previous chapters have noted, regulatory requirements are a significant driver to that end; if the lab won't meet its regulatory requirements, it risks major fines at a minimum, or at worst going out of business. In fact, some 60 percent of small businesses end up closing shop within six months of a cyberattack.[14] This happens for multiple reasons, with costs related to compliance fines, breach notifications, post-breach customer protection, public relations, reputation loss, attorney's fees, litigation, and operational disruption often laying waste to the business.[15] And it happens to businesses in almost every industry.

Laboratories are not exempt from these cyberattacks and losses, whether using on-premises systems or turning to the cloud. In 2019, Canadian laboratory testing business LifeLabs suffered a cyberattack on its systems that saw the attackers steal information and request a ransom to have the data returned. While it's not clear exactly what went wrong, talk of "[f]urther strengthening our systems to deter future incidents"[16] indicates something was off about LifeLabs' computer systems, something that likely could have been prevented with properly managed security services. In 2021, clinical at-home laboratory provider Apex Laboratory announced that it had been attacked by ransomware that hit its systems, which allowed hackers to take sensitive patient information and forcefully encrypt system and other data files until a ransom was paid.[17] This kind of attack also could have been prevented—or the damage at least mitigated—with active MSS protections. And in May 2021, news broke that benevolent hacking group Sakura Samurai, as part of a "vulnerability disclosure program" through the U.S. Department of Energy's Fermilab, had tracked down multiple vulnerabilities in Fermilab's systems, which have since reportedly been corrected.[18][19] Would have a knowledgeable and experienced MSSP caught these issues before Sakura Samurai?

However, the use of an MSSP in the laboratory can't prevent all cases of inadvertently compromising sensitive information. Take for example the case of the Wyoming Department of Health, which accidentally exposed sensitive health information about COVID-19, influenza, and controlled substance analyses in late 2020. An April 2021 news report indicated that more than 164,000 Wyoming residents were affected by the accidental uploading of files containing their testing information as part of a batch file upload to a public-facing GitHub server. While GitHub itself did not cause the release, the upload of the files—which were not intended to be in the upload batch of otherwise normal software code files—to the public servers by the Department of Health did. The Wyoming Department of Health notes that "[b]usiness practices have been revised to include prohibiting the use of GitHub or other public repositories and employees have been retrained."[20]

This statement highlights that, ultimately, internal process and procedure that didn't address the use and corresponding potential risks of public-facing servers within day-to-day operations was to blame. Strictly speaking, any MSS in place could not have prevented the upload to GitHub, unless the MSSP had prior identified this type of risk and brought it to the attention of the laboratory. It's possible an MSSP could have encouraged the lab to turn to group policies or some other access control to limit internet access from laboratory computers[21], though a careful balance of managing security risk with ensuring lab tech productivity would still need to be maintained. However, in the end, this is largely a story of internal laboratory policy, not something an MSS could prevent unless previously anticipated. This naturally brings up the discussion about a laboratory's quality assurance officer and their increasingly important role in addressing cybersecurity and choosing CSPs and MSSPs for the lab.

5.2.1 The quality assurance officer

Quality assurance laboratory 140305-N-OE749-012.jpg

Imagine a medical device manufacturer (which happens to incorporate laboratories, but that's not the main point here). A medical device manufacturer works in a highly regulated industry that not just asks but demands quality from the manufactured medical devices. As many such devices are increasingly electronic—and even network-enabled—it's imperative that cybersecurity is considered in their design and use.[22] As David Jensen of MasterControl noted in 2017: "The technologies that elevate the quality of life for patients can be used by cyber actors to undermine both the manufacturing organization and the products themselves. This means cybersecurity is as much a quality issue as it is a security issue."[23]

Note that Jensen related "cybersecurity" and "quality" together, which naturally leads to a discussion of the quality management system (QMS). A QMS is "a set of related and interacting elements that organizations use to direct and control how quality policies are implemented and quality objectives are achieved."[24] Those elements include, but are not limited to, documented processes, management models, business strategies, human capital, and information technology. Not only does the QMS help guide the implementation and achievement of organizational policy and objectives for resource management and personnel, but also it prompts an organization to focus on the core elements of quality management within its products and services: planning, control, assurance, and improvement. And just as the development and use of a QMS is often driven by standards (e.g., ISO/IEC 17025:2017 and ISO 13485:2016), the QMS often drives the organization to adopt other standards as part of bringing quality to the organization. Using our medical device manufacturer as an example, their QMS may direct them to use the ANSI/CAN/UL 2900-1 standard for ensuring medical device cybersecurity protection.[25]

Not only is the QMS vital to medical device manufacturers[23][26][27][28], but also the QMS plays an important role in most any laboratory's operations.[29][30] And in the laboratory, a quality assurance officer or manager is responsible for helping develop and maintain the laboratory's QMS, which optimally will address the importance of cybersecurity in meeting the laboratory’s goals. But the connection between a laboratory's quality assurance officer and cybersecurity is sadly not well represented in the cloud computing era. Look through the job descriptions on online job boards for quality assurance officers and you will rarely find the word "security" mentioned. Sure, the relationship between "quality" and "security" gets discussed in the context of modern software development[31], but what about within the context of a laboratory's operational quality and the people who drive it forward?

In a 2019 journal article for Lab Manager magazine, Sandia National Laboratories' chief information officer Carol Jones stated that "[c]ybersecurity is not just a technology problem; it is a people, process, and knowledge problem."[32] While this is an accurate statement, shouldn't cybersecurity also be a quality problem for a laboratory? Yes, well-trained people, vetted processes, and relevant and timely knowledge is required to ensure secure operations, but quality management and assurance—which incorporates that training, SOPs, and knowledge—should also be part of that equation. One could argue that the responsibilities of a quality assurance officer or manager are already numerous and weighty. But shouldn't that person at least have a modicum of understanding about how well-implemented IT and software security in the lab correlates to improved quality assurance outcomes?[33]

At this juncture, several questions must be asked about the quality assurance officer or manager in a laboratory operating in the 2020s:

  • What is the importance of the quality assurance officer (QAO), and do they understand cybersecurity?
  • How does the QAO help ensure quality of operations with security as a managed service?
  • How do standard operating procedures (SOPs), security audits, and other elements of a QMS positively affect quality assurance by addressing cybersecurity and cloud hosting processes?

The importance of a QAO and their security knowledge

First, the definition of what a QAO does will largely vary from company to company. However, turning to Bartram and Ballance's 1996 guide Water Quality Monitoring, the author's describe a quality assurance officer as someone "to liaise with management, to manage data archives, to conduct regular audits and reviews of the QA system, and to report on any QA issues to the program or institution manager."[34] They add that the QAO is also "responsible for regularly inspecting all aspects of the [record keeping] system to ensure staff compliance, for reporting on such inspections and audits to management, and for recommending improvements."[34] But what of a more modern definition? Turning to ISO 9000, we get a bland and non-informative definition of quality assurance itself: "part of quality management focused on providing confidence that quality requirements will be fulfilled."[35] By extension, we then get "a person responsible for providing confidence that requirements for organizational quality are fulfilled." This is a broad description, sadly. However, pulling from Bartram and Ballance, the ISO, and other sources[36][37], we could go with something like:

A quality assurance officer (QAO) is an individual responsible for ensuring organizational quality through the regular management, monitoring, review, and auditing of documentation, record systems, data, and processes as they relate to organizational quality and compliance frameworks and initiatives, while also reporting timely results, making recommendations based on those results, and assisting with training staff on approved recommendations.

Given that definition, does the average QAO need to understand at least the basics of cybersecurity? That's arguable, to be sure. After all, there are job positions such as the "cybersecurity quality and compliance officer" and the like[36], with an individual who works directly with an IT department and its cybersecurity team to ensure all mandatory laws and regulatory requirements are being adhered to, much in the same way a QAO does but on a broader organizational basis. But what about the laboratory realm? Major laboratories with significant resources may have these sorts of positions, but smaller, independent labs may not. In that case, laboratory personnel will often wear many hats, including "the tech person" or "laboratory systems engineer." (See Joe Liscouski's discussion of the "laboratory systems engineer" in his 2020 guide Laboratory Technology Planning and Management: The Practice of Laboratory Systems Engineering for more on this topic.[38]) However, given that the security surrounding an organization's electronic efforts is vital to maintaining quality operations, and also given that—hopefully—cybersecurity efforts are documented and trained upon, it's not that far a leap to suggest that the laboratory QAO should have a rudimentary understanding of IT systems and how they are secured. If cybersecurity is interwoven into the laboratory culture, including quality management, the tech-savvy QAO will be a boon to the overall quality assurance process.

The QAO and managed security services

Where does a QAO and an MSS intersect in the lab? Judging by the previous statement that the QAO may need to review organizational documentation and training material regarding cybersecurity—and even audit or assess personnel on their use of that documentation and training—we can see deduce that a QAO may be required to audit the effectiveness of any implemented MSS, or at least the documentation and processes related to the MSS. Again, it's likely in mid- to large size organizations this responsibility will fall upon the shoulders of an IT lead or IT quality officer. However, these resources may not be readily available in some laboratory settings. If those resources aren't available, the QAO may be required to know more than they expected about what managed security services entail. They won't need to be MSS experts, but as the nature of computing in the laboratory continues to evolve, having laboratory staff with relevant knowledge of automation, data management systems, and even the cloud is increasingly vital.[38]

The QMS and cybersecurity

In 2019, scientific and business consultancy Brevitas brought up the challenges of addressing cybersecurity in laboratories and other settings, noting evolving guidance that strives to address the business policies, security controls, informatics systems, and security monitoring required to better ensure the integrity and security of electronic records and data. They are one of a handful of consultancies that have publicly tied these types of standard-driven cybersecurity measures directly to the QMS[39]:

The challenge is in ensuring that these measures are effectively integrated into the existing processes outlined in the organization’s quality management system (QMS). Consideration needs to be given to first integrating cybersecurity into risk and/or criticality assessments, then downstream into system security testing during qualification and/or validation activities. As the technological landscape evolves, organizations must be more effective in their implementation of cybersecurity measures to ensure the safety of their electronic records and data. These measures must be considered as part of the QMS for all activities involved in the lifecycle of a computerized system.

As has been previously mentioned, this type of philosophy is already woven into the fabric of medical device regulation and standardization, with 21 CFR 820 on quality system regulation, ISO 13485:2016 on quality management systems, and ANSI/CAN/UL 2900 on ensuring medical device security driving how medical device cybersecurity is addressed in the manufacturer's quality management system.[28][40][41][42][43] And it may be even easier for medical device manufacturers—as well as other laboratory types—to compile, organize, disseminate, and train upon cybersecurity risk analysis data and procedural documentation with the help of an electronic QMS.[23] However, we can turn to some other businesses who have included security standards in their quality management system. Technology consultancy Konsolute has discussed why it chose to integrate ISO 27001 on information security management (and the information security management system or ISMS) into its business processes and the development of its electronic QMS, noting benefits of improved compliance, lower security risk, improved financial savings, improved reputation, and more new business.[44]

As it turns out, the ISMS and ISO 27001 have a bit in common with the QMS and ISO 9001, primarily with the goal of improving quality within the organization. Here again we see the link between a focus on cybersecurity and ensuring quality within an organization.[45][46] Senior associate Nikita Patel of Schellman & Company highlighted this association in 2017, saying that an organization "achieving this dual certification of an ISO 9001 and ISO 27001 can prove incredibly useful—in doing so, an organization can simultaneously demonstrate an organization’s ability and commitment to information security risk management, while also validating their dedication to the optimal delivery of their quality products and services."[46] From addressing anything from scoping, leadership, human resources support, and document management to internal auditing, measurement and monitoring, management review, and continual improvement, both the ISMS, focused on information security, and QMS, focused on organizational quality, improve the overall quality of an organization and its efforts.

The QAO in the context of these three points

Where does this all place the quality assurance officer in the scope of laboratory quality and information security? Whether it's managed security services, private or public cloud services, in-house networking, or a mix of all these, the modern laboratory is a technology-driven business requiring modern approaches to addressing the risks that technology carries with it. An on-site IT staff may handle many of the details associated with those efforts, but the QAO of the 2020s needs to also be familiar with how that technology works and how it impacts organizational quality initiatives. The QAO will interact with the lab's QMS, and perhaps even the ISMS if one separately exists. Ideally cybersecurity policy and procedure will already be woven into the various elements of the QMS, or, worst case, the lab doesn't have much of a cybersecurity policy. This is where the QAO of today's lab must shine, "ensuring organizational quality through the regular management, monitoring, review, and auditing of documentation, record systems, data, and processes as they relate to organizational quality and compliance frameworks and initiatives." That means also understanding how managed security services and cloud services operate. It's perhaps a tall ask, but in today's competitive laboratory environment, the tech-savvy QAO is more important than ever.

5.2.2 The shared responsibility model in the scope of security management and quality assurance

Before we move on to choosing an MMSP, we need to briefly mention the shared responsibility model and how it relates to both the MSSP's (and CSP’s) services and assuring quality within the laboratory. Back in Chapter 2, we discussed the shared responsibility model, occasionally referred to as the "shared security model." We said the shared responsibility model is useful because it clarifies elements of responsibility for information security between the laboratory and the CSP in regards to provided cloud services. A trusted CSP should be able to make both levels of responsibility clear at every step of the way, from early contract discussions to late-stage changes to customer services. The CSP remains responsible for certain levels of the IT infrastructure and software, while the laboratory remains responsible for the security of the guest OS, account security, firewall settings, and more. This delineation of responsibility varies from provider to provider, but optimally the information is related clearly to the lab by each.

When it comes to MSSPs and the cloud, they are capable of further reducing the burden of responsibility the laboratory has in regards to not only their cloud services but also any networked on-premises systems. An MSSP can take on the responsibility of the guest OS, network configuration, firewall settings, and server-side encryption, as well as a select portion of client-side data encryption, data integrity authentication, application hardening, and network traffic monitoring and protection.[47][48] This frees the laboratory from even more security detail, providing monetary, quality, and time investment benefits. As noted earlier, however, the laboratory is not completely free from worrying about security. A company culture of cybersecurity and quality must continue to be driven by strong management buy-in, well-documented business and quality policies, well-considered and -enforced operational policies, and regular quality training.

That said, how does the shared responsibility model affect the work of the QAO and laboratory's overall efforts to ensure security in the cloud, particularly with an MSSP? Primarily, shared responsibility says that the laboratory can't take a "set it and forget it" approach to security, even with a CSP and MSSP taking a significant portion of the responsibility off the laboratory's hands. Going back to the Wyoming Department of Health and its accidental upload of patient data to a public server, neither a cloud provider nor an MSSP could do much in this situation. We don't know the circumstances and technology surrounding their incident, but let's imagine that the public health lab was using a CSP and an MSSP. Certainly, the CSP would have no real say in how the lab uploaded content to a server outside its domain. The MSSP largely would have no blame either, as they likely wouldn't even be aware of the public server being uploaded to. No, that would be an internal policy issue, a solid example of how the laboratory would still have a shared stake in the responsibility of security at the lab.

From that example, we'd have to turn to the work of laboratory staff and management, including the QAO. Again, imagining a scenario where the lab was using both a CSP and an MSSP, a number of questions would arise, primary among them being "were they fully aware of and committed to the security responsibility they shared with their service providers?" That level of responsibility would include engaging in cybersecurity discussions among management and key IT personnel, having frank discussions about risk, and bringing in outside help where expertise was lacking. It would also include having a thorough understanding of how lab workers do their job, including learning about any public servers they were using. And it would also, ideally, involve discussion about that laboratory workflow with the MSSP. With all these elements, the likelihood of foreseeing the risk associated with uploading data to public servers from laboratory computers would be optimistically high. Finally, if we add the element of either a laboratory QAO or "cybersecurity quality and compliance officer," one could imagine the scenario turning out differently for the Department of Health. In the end, however, it would have still required knowledgeable personnel, a strong laboratory-wide focus on cybersecurity, and a committed QAO familiar with the importance of the shared responsibility model—and at least the basics of information security—to help ensure the quality of laboratory operations and the information security required of them.

5.3 Choosing a provider for managed security services


Many MSSP options exist for labs seeking MSS. (Appendix 2 of this guide provides a list of profiles for top MSSPs to consider.) In some cases, if the lab is already using a public or hybrid cloud provider, that provider may already offer MSS to its customers, providing a certain level of convenience and familiarity to the lab. (For example, both IBM and Cisco, which offer public and hybrid cloud services, are ranked among the top 70 MSSPs in several publications.[49][50][51]) However, in some cases it may make sense for the lab to look beyond their cloud provider, particularly if their cloud provider doesn't supply MSS to its clients.

As discussed prior, a knowledgeable and well-run MSSP can provide many benefits to the cloud-based lab, but what should stand out about the MSSP you select? When choosing a provider of comprehensive cloud-based MSS, you'll be looking for not only years of experience managing cloud installations, but also that the provider is able to[4][52][53][54]:

  • demonstrate deep knowledge of cloud-agnostic, industry-relevant best practices and approaches to security frameworks and their implementation;
  • demonstrate deep knowledge of regulatory mechanisms affecting your data and how to approach cloud security based upon those regulatory requirements;
  • describe what certifications, training, and continuing education requirements are met by staff;
  • leverage existing and emerging cloud security tools (e.g., security information and event management [SIEM] software) for automating security processes in a scalable future-proof fashion;
  • validate how their cloud security tools accomplish what they're intended to do, as well as how gathered information is analyzed both automatically and by the provider's analysts;
  • demonstrate how their approaches to security management can fit into or further mold your current IT and risk management strategies;
  • provide transparent pricing (e.g., is it tiered or bundled, based on number of users, something else) and make clear what the service covers;
  • provide examples of existing and past customers willing to give feedback about their experience with the provider;
  • provide a single point of contact to act as a security advocate to you during the entirety of your contract; and
  • support not only open-source security management tools, but also be flexible enough to integrate your own proprietary solutions and their associated licenses into the managed service.

Of course, cost will also be of concern. However, a blanket "how much does it cost" question isn't going to produce a simple answer; there will be many variables (e.g., business needs, current solutions, current IT staffing, regulatory requirements, etc.) within your organization that make it difficult for an MSSP to provide a canned response. They will need to respond to your lab’s needs, which may be different from another lab's.[55] Additionally, costs associated with MSS can vary, not only from provider to provider but also based upon each provider's pricing model. Will they charge your lab based upon number of users, number of devices, or some other mechanism? Does the MSSP provide a flat rate for protecting your cloud resources, or do they offer different tiers or bundles of services? And will the MSSP providing cloud-based MMS also manage your non-cloud resources? A "per user" or "per device" approach to pricing may make sense for small labs, but larger organizations may balk at such inflated costs, preferring a flat rate or tiered package of services. Those tiered services may be based on either a user number range or based on a set of offered services.[52]

Ultimately, before approaching an MSSP, your lab will have needed to go through multiple steps internally, stating IT goals, identifying technology and education gaps, and determining a budget to support those goals and gaps. If your lab doesn't have a clear picture of what it has, where it wants to be, and what it will need to get there, it will make selection process even more difficult. As such, your lab may want to consider the request for information (RFI) process as part of your selection process.

5.3.1 Using a request for information (RFI) process

In some cases—particularly if your organization is of significant size—it may make sense to issue a formal RFI or request for proposal (RFP) and have major cloud MSSPs approach your lab with how they can meet its needs. The RFI and RFP are traditional means towards soliciting bidding interest in an organization's project, typically containing the organization's specific requirements and vital questions that the bidder should be able to effectively answer. However, even if your organization chooses to do most of the investigative work of researching and approaching cloud MSSPs, turning to a key set of questions typically found in an RFI is extremely valuable for "fact finding."

An RFI is an ideal means for learning more about a potential solution and how it can solve your problems, or for when you're not even sure how to solve your problem yet. However, the RFI should not be unduly long and tedious to complete for prospective vendors; it should be concise, direct, and honest. This means not only presenting a clear and humble vision of your own organization and its goals, but also asking just the right amount of questions to allow potential vendors to demonstrate their expertise and provide a clearer picture of who they are. Some take a technical approach to an RFI, using dense language and complicated spreadsheets for fact finding. However, vendors appreciate a slightly more inviting approach, with practical questions or requests that are carefully chosen because they matter to you.[56] Remember, however, that an RFI is not meant to answer all of your questions. The RFI is meant as a means to help narrow down your search to a few quality candidates while learning more about each other.[56] Once the pool of potential MSSPs is narrowed down, more pointed questions can be asked to ensure those providers meet your needs.

Be cognizant, however, that just like CSPs, there may be no MSSP that can meet each and every need of your lab. Your lab will have to make important decisions about which requirements are non-negotiable and which are more flexible. The MSSPs you engage with may be able to provide realistic advice in this regard, based upon your lab's requirements and their past experience with labs. As such, those MSSPs with real-world experience protecting the information systems of laboratories may have a strong leg up on other MSSPs, as they can make informed comments about your lab’s requirements based on their past experiences.

For your convenience, Appendix 3 of this guide includes a comprehensive list of RFI questions to ask of MSSPs, as well as cloud providers. If you have zero experience developing an RFI, you may want to first seek out various example RFIs on the internet, as well as some basic advice articles on the topic. Some websites may provide templates to examine for further details. However, the templates in Appendix 3 attempt to provide basic background about the RFI process as well. This includes addressing important questions related to your business so providers responding to your RFI better understand your lab's goals and requirements.

Now that we've addressed MSSPs, it's time to move on and take a look at the considerations required when choosing and implementing a cloud solution. The next chapter will look at the various characteristics of an average cloud provider, what you should look for in a cloud provider, the questions your organization should ask of itself, and the questions your organization should be asking cloud providers.


  1. 1.0 1.1 "Managed Security Service Provider (MSSP)". Gartner Glossary. Gartner, Inc. Retrieved 28 July 2023. 
  2. "Managed security services (MSS)". IBM. Retrieved 28 July 2023. 
  3. "The REAL Benefits of a Managed Security Service Provider (MSSP)". SecureOPS. 26 August 2020. Archived from the original on 14 May 2021. Retrieved 28 July 2023. 
  4. 4.0 4.1 4.2 4.3 "How Managed Cloud Security Works, and Why You Might Want It". Trianz. 29 March 2021. Retrieved 28 July 2023. 
  5. Federal Financial Institutions Examination Council (June 2004). "Outsourcing Technology Services" (PDF). FFIEC. Archived from the original on 01 February 2022. Retrieved 28 July 2023. 
  6. Smallwood, R.F. (2014). "Chapter 1: The Onslaught of Big Data and the Information Governance Imperative". Information Governance: Concepts, Strategies, and Best Practices. Wiley. pp. 3–13. ISBN 9781118218303. 
  7. O'Neill, S. (22 October 2015). "Information Governance: A Principled Framework". Daymark Blog. Retrieved 28 July 2023. 
  8. Dotson, C. (2019). "Chapter 7: Detecting, Responding to, and Recovering from Security Incidents". Practical Cloud Security: A Guide for Secure Design and Deployment. O'Reilly Media. pp. 139–71. ISBN 9781492037514. 
  9. VirtualArmour International (8 April 2019). "VirtualArmour Expands Managed Cybersecurity Services with Global Gemological Organization". Intrado GlobeNewswire. Retrieved 28 July 2023. 
  10. PreScouter (October 2017). "Managed Cybersecurity Service Providers for Electric Utilities" (PDF). American Public Power Association. Retrieved 28 July 2023. 
  11. "Case Study: Managed Detection Response for Toxicology Laboratory". Frontier Technologies, Inc. 2020. Archived from the original on 14 April 2021. Retrieved 28 July 2023. 
  12. "Healthcare Managed Security Services Forum". Cylera. November 2020. Retrieved 28 July 2023. 
  13. "Putting Information Exchange to Work for Healthcare". ANXeBusiness Corp. Retrieved 28 July 2023. 
  14. Galvin, J. (7 May 2018). "60 Percent of Small Businesses Fold Within 6 Months of a Cyber Attack. Here's How to Protect Yourself". Retrieved 28 July 2023. 
  15. "BLOG: Cost of Cyber Crime to Small Businesses". Virginia SBDC Blog. Virginia SBDC. 30 May 2017. Archived from the original on 27 December 2020. Retrieved 28 July 2023. 
  16. "Canadian Lab Test Firm LifeLabs Pays Ransom After Data Breach". Security. BNP Media. 26 December 2019. Retrieved 28 July 2023. 
  17. Arghire, I. (4 January 2021). "Apex Laboratory Says Patient Data Stolen in Ransomware Attack". Security Week. Retrieved 28 July 2023. 
  18. Kirk, J. (7 May 2021). "US Physics Laboratory Exposed Documents, Credentials". Bank Info Security. Retrieved 28 July 2023. 
  19. Willis, R. (6 May 2021). "Fermilab Hack, April/May 2021". Robert Willis Hacking. Retrieved 28 July 2023. 
  20. Flack, B. (27 April 2021). "Wyoming Department of Health Announces Data Breach of Thousands of Wyoming Residents". SweetwaterNow. Archived from the original on 27 April 2021. Retrieved 28 July 2023. 
  21. Paul (3 June 2019). "How To Restrict Internet Access Using Group Policy (GPO)". The Sysadmin Channel. Retrieved 03 June 2019. 
  22. Nayyar, S. (22 December 2020). "The Unique Threats Posed By Medical IoT Devices And What To Do About Them". Forbes. Retrieved 28 July 2023. 
  23. 23.0 23.1 23.2 Jensen, D. (3 June 2017). "How an Electronic Quality Management System Helps With Cybersecurity". MasterControl. Archived from the original on 23 May 2021. Retrieved 28 July 2023. 
  24. Shoemaker, D.; Sigler, K. (2014). Cybersecurity: Engineering a Secure Information Technology Organization. Cengage Learning. pp. 62–63. ISBN 9781285169903. 
  25. Wirth, A.; Gates, C.; Smith, J. (2020). Medical Device Cybersecurity for Engineers and Manufacturers. Artech House. pp. 23–24. ISBN 9781630818159. 
  26. Therapeutic Goods Administration (March 2021). "Medical device cyber security guidance for industry" (PDF). Commonwealth of Australia. Retrieved 28 July 2023. 
  27. "Risk Management Best Practices for Cybersecurity Compliance". AssurX Blog. AssurX, Inc. 30 January 2017. Retrieved 28 July 2023. 
  28. 28.0 28.1 "Cybersecurity & Quality Management System Integration". Apraciti. Retrieved 28 July 2023. 
  29. World Health Organization (2011). Laboratory Quality Management System Handbook. World Health Organization. ISBN 9789241548274. 
  30. United States Geological Survey. "Quality Management System for USGS Laboratories". United States Geological Survey. Retrieved 28 July 2023. 
  31. Worrall, J. (18 August 2020). "Why Quality & Security Both Matter in Software". DarkReading. Retrieved 28 July 2023. 
  32. Tulsi, B.B. (4 September 2019). "Greater Awareness and Vigilance in Laboratory Data Security". Lab Manager. Retrieved 28 July 2023. 
  33. Hamidovic, H. (2012). "Fundamental Concepts of IT Security Assurance". ISACA Journal 2: 45–9. 
  34. 34.0 34.1 Bartram, J.; Ballance, R., ed. (2020). Water Quality Monitoring: A practical guide to the design and implementation of freshwater quality studies and monitoring programmes. CRC Press. p. 218. ISBN 9780419223207. 
  35. "ISO 9000:2015(en) Quality management systems — Fundamentals and vocabulary". ISO. 2015. Retrieved 28 July 2023. 
  36. 36.0 36.1 Genesis IT&T (10 May 2021). "Cybersecurity Quality and Compliance Officer - 6 Month Contract". Seek. Archived from the original on 28 July 2023. Retrieved 28 July 2023. 
  37. "Quality Control Officer - What They Do". Zippia. Retrieved 28 July 2023. 
  38. 38.0 38.1 Liscouski, J. (December 2020). "Laboratory Technology Planning and Management: The Practice of Laboratory Systems Engineering". 
  39. "Cybersecurity Response". Brevitas. 2019. Retrieved 28 July 2023. 
  40. Lincoln, J.E. (17 April 2017). "Cybersecurity - Buzzword or Serious Safety Concern?". IVT Network. Archived from the original on 25 May 2021. Retrieved 28 July 2023. 
  41. Heyl, J. (October 2017). "Overview of UL 2900 - Medical Device Cybersecurity Workshop" (PDF). UL. Retrieved 28 July 2023. 
  42. "UL 2900: A Cybersecurity aid for industry and regulators" (PDF). UL. 2019. Retrieved 28 July 2023. 
  43. "ISO 13485:2016 Medical devices — Quality management systems — Requirements for regulatory purposes". ISO. March 2016. Retrieved 28 July 2023. 
  44. "Cybersecurity of the future: Why we include ISO 27001 as standard in our Quality Management System". Konsolute. 30 April 2021. Retrieved 28 July 2023. 
  45. "Information Security Management System (ISMS)". CVG Strategy. 2020. Retrieved 28 July 2023. 
  46. 46.0 46.1 Patel, N. (16 October 2017). "ISO 9001 and 27001 – The Relationship". Schellman Blog. Schellman & Company. Archived from the original on 28 February 2021. Retrieved 28 July 2023. 
  47. Wang, K. (14 October 2020). "Shared Responsibility in the Cloud: Reduce Your Security Burden With a Managed Security Service Provider (MSSP)". Cloudticity Blog. Cloudticity. Retrieved 28 July 2023. 
  48. Savir, L. (20 July 2024). "How a Managed Service Provider Can Harden Security Across Your Business and Save on Costs". AllCloud Blog. Retrieved 28 July 2023. 
  49. "Top 250 MSSPs for 2022: Companies 70 to 61". Top 250 MSSPs: Cybersecurity Company List and Research for 2020. MSSP Alert. September 2022. Retrieved 01 August 2023. 
  50. "Top 100 Managed Security Service Providers (MSSPs)". Cyber Defense Magazine. Cyber Defense Media Group. 18 February 2021. Retrieved 01 August 2023. 
  51. "Top 15 Best Managed Security Service Providers (MSSPs) In 2023". Software Testing Help. 14 July 2023. Retrieved 28 July 2023. 
  52. 52.0 52.1 "How Much Does Managed Security Services Cost?". RSI Security. 20 August 2020. Retrieved 28 July 2023. 
  53. Russell, J. (10 January 2022). "10 Tips for selecting a Managed Security Services Provider (MSSP)". HarmonyTech Blog. Retrieved 28 July 2023. 
  54. "How to Choose an MSSP" (PDF). NTT Security. November 2016. Archived from the original on 08 May 2021. Retrieved 28 July 2023. 
  55. Dosal, E. (2 May 2019). "Is Managed Security Worth the Cost?". Compuquip Blog. Retrieved 28 July 2023. 
  56. 56.0 56.1 Holmes, T.. "It's a Match: How to Run a Good RFI, RFP, or RFQ and Find the Right Partner". AllCloud Blog. Retrieved 28 July 2023. 

-----Go to the next chapter of this guide-----

Citation information for this chapter

Chapter: 5. Managed security services and quality assurance

Title: Choosing and Implementing a Cloud-based Service for Your Laboratory

Edition: Second edition

Author for citation: Shawn E. Douglas

License for content: Creative Commons Attribution-ShareAlike 4.0 International

Publication date: August 2023