User:Shawndouglas/sandbox/sublevel18 - Revision history

Shawndouglas: Replaced content with "
TOC
{{ombox | type = notice | style = width: 960px; | text = This is sublevel18 of my sandbox, where I play with features and..."

2023-08-16T20:11:09Z

Replaced content with "<div class="nonumtoc">__TOC__</div> {{ombox | type = notice | style = width: 960px; | text = This is sublevel18 of my sandbox, where I play with features and..."

← Older revision		Revision as of 20:11, 16 August 2023
Line 7:		Line 7:

	==Sandbox begins below==		==Sandbox begins below==
	~~==3. Organizational cloud computing risk management==~~
	[[File:NISTRiskManApproach.png\|right\|550px\|thumb\|'''Figure 4.''' A diagram of an organization-wide risk management approach, as published in NIST SP 800-37 Rev. 2. NIST says this diagram "addresses security and privacy risk at the organization level, the mission/business process level, and the information system level. Communication and reporting are bi-directional information flows across the three levels to ensure that risk is addressed throughout the organization."<ref name="NISTSP800-37v2_18" />]]After discussing cloud standards, regulations, and security, it makes sense to next address the topic of [[cloud computing]] [[risk management]]. Risks beget risk management, which in turn begets security. Whether the risks are near the home, on an airplane, or with an online bank account, risk management practices limit the risks, usually through some mechanism of "security." "The five-year crime numbers in my neighborhood are going up," one might assess. "I shall manage the risk with a home security system," is the risk management action performed. In the same way, engineers add multiple layers of redundancy to an airplane's components to mitigate the assessed risk of instrument failure, and banks require access controls like strong passwords on online accounts to protect customer data and limit their liability. As such, it shouldn't be surprising to talk about employing security and process control measures as part of managing risks in the cloud.

	We learned in the last chapter that the National Institute of Standards and Technology (NIST) represents a strong example of a standards and recommendations body in the U.S. In their 2018 SP 800-37 Rev. 2 ''Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy'', NIST says the following about risk management for information systems<ref name="NISTSP800-37v2_18">{{cite web \|url=https://csrc.nist.gov/pubs/sp/800/37/r2/final \|title=SP 800-37 Rev. 2: Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy \|author=National Institute of Standards and Technology \|date=December 2018 \|accessdate=28 July 2023}}</ref>:

	<blockquote>Managing information system-related security and privacy risk is a complex undertaking that requires the involvement of the entire organization—from senior leaders providing the strategic vision and top-level goals and objectives for the organization, to mid-level leaders planning, executing, and managing projects, to individuals developing, implementing, operating, and maintaining the systems supporting the organization’s missions and business functions. Risk management is a holistic activity that affects every aspect of the organization, including the mission and business planning activities, the enterprise architecture, the SDLC processes, and the systems engineering activities that are integral to those system life cycle processes.</blockquote>

	As Figure 4—from the same NIST guide—notes, there are three main levels at which an organization must approach risk management activities for their information systems: the organization level, the mission/business process level, and the information system level. The arrow on the left highlights the criticality of proper communication across all three levels in order for the organization to make the most of their risk management activities. Just as IT forms the base of any software-driven business efforts, critical stakeholders in IT form the base of communication about IT risk and security requirements. Without those stakeholders' knowledge and feedback, business processes and company policy would be ill-informed. Now let's start from the top of the pyramid and head downward. Note that without strong leadership, well-crafted business goals, and management buy-in on quality, budget, and security, business processes would be a mess and IT-related efforts would be sub-par and at-risk.

	The implication with Figure 4 and NIST's guide is that effective planning and communication is critical to ensuring information systems are implemented securely during their entire life cycle. Many organizations approach this task by developing, implementing, and enforcing a [[cybersecurity]] plan, in which identifying cybersecurity requirements and objectives—i.e., [[risk assessment]] and management—is a vital component. (See the ''[[LII:Comprehensive Guide to Developing and Implementing a Cybersecurity Plan\|Comprehensive Guide to Developing and Implementing a Cybersecurity Plan]]'' for much more on this topic.)


	~~===3.1 Five risk categories to consider===~~
	In January 2021, ''Business Tech Weekly'' highlighted the biggest security challenges to organizations adopting cloud. Among them were<ref name="AntonenkoCloud21">{{cite web \|url=https://www.businesstechweekly.com/cybersecurity/data-security/cloud-computing-security-issues-and-challenges/ \|title=Cloud computing security issues and challenges \|author=Antonenko, D. \|work=Business Tech Weekly \|date=04 January 2021 \|accessdate=28 July 2023}}</ref>:

	* inadequate access control
	* insufficient contract regulation
	* unsecure software interfaces
	* low data visibility
	* delays in deleting data
	* inability to maintain regulatory compliance

	These and other related challenges are a product of the various risks of doing business in the cloud. Those risks—in the scope of business, essentially aspects of business and the environment it operates in that endanger objectives—in turn must be managed to better ensure an organization meets its goals. This requires risk management.

	Risk management is the process of identifying, evaluating, and prioritizing risks, and then developing an economical and efficient strategy for monitoring, controlling, and mitigating those risks. Whether risk management is part of an overall cybersecurity plan (as it should be) or an independent process (perhaps more common in really small organizations), it always makes sense to have strategies for managing threats and responding to opportunities, not only for the organization as a whole but also specifically for IT and software implementations.

	But what are the major risks associated with cloud computing initiatives that drive the need for risk management? And what are the potential consequences if those risks are left unchecked? Business consultancy KPMG released a 2018 report about managing risk in the cloud. In that report, author Sai Gadia identified five critical categories of risk to organizations venturing into the cloud: data security and regulatory risk, technology risk, operational risk, vendor risk, and financial risk.<ref name="GadiaHowTo18">{{cite web \|url=https://assets.kpmg.com/content/dam/kpmg/ca/pdf/2018/03/cloud-computing-risks-canada.pdf \|format=PDF \|title=How to manage five key cloud computing risks \|author=Gadia, S. \|publisher=KPMG LLP \|date=March 2018 \|accessdate=28 July 2023}}</ref>

	~~These five categories neatly sum up the areas of risk to apply and cloud risk assessment, but let's look at them a bit more closely.~~

	~~'''Data security and regulatory risk''': This category examines the concerns of [[data integrity]] and availability.~~
	* ''The potential risks'': data is leaked, lost, or becomes unavailable.
	* ''The potential consequences'': reputation loss, regulatory non-compliance, business interruptions, and loss of revenue.
	* ''The challenges associated with limiting those potential risks and consequences when embracing a cloud computing initiative'': maintaining enforcement of existing corporate security policies, maintaining regulatory compliance, managing user access effectively, managing networking across multitenancy or shared infrastructures, and gaining greater flexibility with encryption and security controls offered by the cloud service provider (CSP).
	* ''Getting around these challenges'': Organizations should "have mature data protection and regulatory compliance programs staffed with talented individuals who have sufficient authority and clear responsibilities. Such organizations also leverage leading third-party or homegrown automated tools and continuously improve their capabilities."<ref name="GadiaHowTo18" />

	~~'''Technology risk''': This category examines the concerns of rapid shifts in underlying technologies.~~
	* ''The potential risks'': cloud-specific technologies rapidly evolve, and standardization of those technologies doesn't keep up.
	* ''The potential consequences'': added costs associated with rearchitecting cloud systems, shifting data to new platforms, developing new integrations, and requiring additional training.
	* ''The challenges associated with limiting those potential risks and consequences when embracing a cloud computing initiative'': maintaining room in the budget for rearchitecting cloud applications and systems periodically, maintaining the personnel to stay engaged and focused on changes happening in the industry, and identifying tools (e.g., dashboards) that can extend the life cycle of your cloud implementation.
	* ''Getting around these challenges'': Organizations should "recognize that cloud will require the role and responsibilities of in-house IT professionals to evolve and are making the necessary investment to train individuals and encourage the adoption of innovative technology. In the process, they are also increasing alignment with the vision and business of the organization."<ref name="GadiaHowTo18" /> IT professionals should also be considering aspects of cloud such as compatibility with other CSPs as new services are added.

	~~'''Operational risk''': This category examines the concerns of how IT services and tasks get effectively performed.~~
	* ''The potential risks'': suboptimal service reliability; suboptimal service features; insufficient control over the underlying service; and theft, fires, and other natural disasters.
	* ''The potential consequences'': costly downtime, slower workflows, slower disaster recoveries, and permanent losses of vital assets.
	* ''The challenges associated with limiting those potential risks and consequences when embracing a cloud computing initiative'': maintaining room in the budget for leading technologies, maintaining room in the budget for a service that meets most if not all workflow and regulatory requirements, having the budget and knowledge to implement redundant systems (e.g., via hybrid cloud), and being able to rapidly bounce back from asset losses.
	* ''Getting around these challenges'': Organizations should "adopt the agile development methodology as well as the DevOps model for cloud deployments. Such organizations are now using the learning from pilot projects to shape the enterprise development methodologies of the future."<ref name="GadiaHowTo18" /> Additionally, they should investigate how to best cost-optimize redundant cloud storage based on access patterns, geography, etc.<ref name="WaibelCost17">{{cite journal \|title=Cost-optimized redundant data storage in the cloud \|journal=Service Oriented Computing and Applications \|name=Waibel, P.; Matt, J.; Hochreiner, C. et al. \|volume=11 \|pages=411–26 \|year=2017 \|doi=10.1007/s11761-017-0218-9}}</ref> Additionally, if the organization is responsible for localized (i.e., private cloud) assets housing critical operational data and equipment, the organization should have sufficient plans in place on how to mitigate risks from physical disasters and other threats to that data and equipment.

	~~'''Vendor risk''': This category examines the concerns of doing business with a CSP.~~
	* ''The potential risks'': vendor files for bankruptcy, is named in a lawsuit, is scrutinized by a regulatory body, or otherwise has an underlying lack of sustainability or compliance.
	* ''The potential consequences'': loss of data, loss of service, reduced service, and lack of compliance (which has its own costs to an organization).
	* ''The challenges associated with limiting those potential risks and consequences when embracing a cloud computing initiative'': knowing the deep inner workings of the CSP, knowing the financial stability of the CSP, knowing the CSP's true reputation among a wide number of other customers, and putting faith in the CSP's trust center materials.
	* ''Getting around these challenges'': Organizations should "take a long-term strategic view to manage their relationships with cloud service providers. Such companies are actively engaged and are shaping the road map of CSPs' service offerings to help accelerate their move to cloud while being offered better tools by the CSP to efficiently manage risks."<ref name="GadiaHowTo18" /> This long-term strategic view should include significant due diligence about the vendor's underlying operations, stability, and fall-back plans should they suffer a major business loss.

	~~'''Financial risk''': This category examines the concerns of the organization’s long-term revenues and ability to budget for cloud services.~~
	* ''The potential risks'': underestimating initial implementation costs, long-term service costs, long-term capital expenditure carry-over (if any), and long-term business revenues.
	* ''The potential consequences'': cost overruns, layoffs, budget cut-backs, and detrimental scaling back of necessary services.
	* ''The challenges associated with limiting those potential risks and consequences when embracing a cloud computing initiative'': finding and retaining experienced and knowledgeable staff capable of budgeting future (and changing) cloud costs, as well as managing the financial activities of the organization.
	* ''Getting around these challenges'': Organizations should “assign individuals with the responsibility for budgeting, tracking, and managing cloud costs. Such organizations are also making use of advanced third-party analytical tools available to manage cloud costs.”<ref name="GadiaHowTo18" /> Estimating those costs can be challenging, particularly in industries where high-throughput data is being created and managed. As such, negotiating a special agreement with the CSP may be of value.<ref name="NavaleCloud18">{{cite journal \|title=Cloud computing applications for biomedical science: A perspective \|journal=PLoS Computational Biology \|author=Navale, V.; Bourne, P.E. \|volume=14 \|issue=6 \|at=e1006144 \|year=2018 \|doi=10.1371/journal.pcbi.1006144 \|pmid=29902176 \|pmc=PMC6002019}}</ref> Also, ensure the organization is considering costs associated with contract modifications and cancellation fees.

	When identifying risks associated with doing business in the cloud, most likely you'll be able to fit them into one of these five categories. As indicated above, potential consequences come with potential risks, and you'll want to identify those consequences. Of course, it's not a simple matter of addressing those risks and consequences; they come with their own challenges. Identifying risks and consequences, and the challenges surrounding and limiting them, are all part of risk management. Finally, after identifying risks, consider the usefulness of an external review of those risks to ensure your organization hasn't missed anything significant.<ref name="DeloitteFFIEC20">{{cite web \|url=https://www2.deloitte.com/content/dam/Deloitte/us/Documents/financial-services/cloud-security-for-FSI.pdf \|format=PDF \|title=FFIEC statement on risk management for cloud computing services \|author=Bhat, V.; Kapur, S.; Hodgkinson, S. et al. \|publisher=Deloitte Development, LLC \|date=2020 \|accessdate=28 July 2023}}</ref>

	~~But how does an organization successfully go through the risk management process? That's best accomplished with the aid of one or more risk management and cybersecurity frameworks.~~

Shawndouglas at 18:58, 15 August 2023

2023-08-15T18:58:53Z

← Older revision		Revision as of 18:58, 15 August 2023
Line 8:		Line 8:
	==Sandbox begins below==		==Sandbox begins below==
	==3. Organizational cloud computing risk management==		==3. Organizational cloud computing risk management==
	[[File:NISTRiskManApproach.png\|right\|~~450px~~\|thumb\|'''Figure 4.''' A diagram of an organization-wide risk management approach, as published in NIST SP 800-37 Rev. 2. NIST says this diagram "addresses security and privacy risk at the organization level, the mission/business process level, and the information system level. Communication and reporting are bi-directional information flows across the three levels to ensure that risk is addressed throughout the organization."<ref name="NISTSP800-37v2_18" />]]After discussing cloud standards, regulations, and security, it makes sense to next address the topic of [[cloud computing]] [[risk management]]. Risks beget risk management, which in turn begets security. Whether the risks are near the home, on an airplane, or with an online bank account, risk management practices limit the risks, usually through some "security." "The five-year crime numbers in my neighborhood are going up," one might assess. "I shall manage the risk with a home security system," is the risk management action performed. In the same way, engineers add multiple layers of redundancy to an airplane's components to mitigate the assessed risk of instrument failure, and banks require access controls like strong passwords on online accounts to protect customer data and limit their liability. As such, it shouldn't be surprising to talk about employing security and process control measures as part of managing risks in the cloud.		[[File:NISTRiskManApproach.png\|right\|550px\|thumb\|'''Figure 4.''' A diagram of an organization-wide risk management approach, as published in NIST SP 800-37 Rev. 2. NIST says this diagram "addresses security and privacy risk at the organization level, the mission/business process level, and the information system level. Communication and reporting are bi-directional information flows across the three levels to ensure that risk is addressed throughout the organization."<ref name="NISTSP800-37v2_18" />]]After discussing cloud standards, regulations, and security, it makes sense to next address the topic of [[cloud computing]] [[risk management]]. Risks beget risk management, which in turn begets security. Whether the risks are near the home, on an airplane, or with an online bank account, risk management practices limit the risks, usually through some mechanism of "security." "The five-year crime numbers in my neighborhood are going up," one might assess. "I shall manage the risk with a home security system," is the risk management action performed. In the same way, engineers add multiple layers of redundancy to an airplane's components to mitigate the assessed risk of instrument failure, and banks require access controls like strong passwords on online accounts to protect customer data and limit their liability. As such, it shouldn't be surprising to talk about employing security and process control measures as part of managing risks in the cloud.

	We learned in the last chapter that the National Institute of Standards and Technology (NIST) represents a strong example of a standards and recommendations body in the U.S. In their 2018 SP 800-37 Rev. 2 ''Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy'', NIST says the following about risk management for information systems<ref name="NISTSP800-37v2_18">{{cite web \|url=https://csrc.nist.gov/pubs/sp/800/37/r2/final \|title=SP 800-37 Rev. 2: Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy \|author=National Institute of Standards and Technology \|date=December 2018 \|accessdate=28 July 2023}}</ref>:		We learned in the last chapter that the National Institute of Standards and Technology (NIST) represents a strong example of a standards and recommendations body in the U.S. In their 2018 SP 800-37 Rev. 2 ''Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy'', NIST says the following about risk management for information systems<ref name="NISTSP800-37v2_18">{{cite web \|url=https://csrc.nist.gov/pubs/sp/800/37/r2/final \|title=SP 800-37 Rev. 2: Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy \|author=National Institute of Standards and Technology \|date=December 2018 \|accessdate=28 July 2023}}</ref>:

Shawndouglas at 17:28, 26 July 2023

2023-07-26T17:28:14Z

← Older revision		Revision as of 17:28, 26 July 2023
Line 7:		Line 7:

	==Sandbox begins below==		==Sandbox begins below==
			==3. Organizational cloud computing risk management==
			[[File:NISTRiskManApproach.png\|right\|450px\|thumb\|'''Figure 4.''' A diagram of an organization-wide risk management approach, as published in NIST SP 800-37 Rev. 2. NIST says this diagram "addresses security and privacy risk at the organization level, the mission/business process level, and the information system level. Communication and reporting are bi-directional information flows across the three levels to ensure that risk is addressed throughout the organization."<ref name="NISTSP800-37v2_18" />]]After discussing cloud standards, regulations, and security, it makes sense to next address the topic of [[cloud computing]] [[risk management]]. Risks beget risk management, which in turn begets security. Whether the risks are near the home, on an airplane, or with an online bank account, risk management practices limit the risks, usually through some "security." "The five-year crime numbers in my neighborhood are going up," one might assess. "I shall manage the risk with a home security system," is the risk management action performed. In the same way, engineers add multiple layers of redundancy to an airplane's components to mitigate the assessed risk of instrument failure, and banks require access controls like strong passwords on online accounts to protect customer data and limit their liability. As such, it shouldn't be surprising to talk about employing security and process control measures as part of managing risks in the cloud.

			We learned in the last chapter that the National Institute of Standards and Technology (NIST) represents a strong example of a standards and recommendations body in the U.S. In their 2018 SP 800-37 Rev. 2 ''Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy'', NIST says the following about risk management for information systems<ref name="NISTSP800-37v2_18">{{cite web \|url=https://csrc.nist.gov/pubs/sp/800/37/r2/final \|title=SP 800-37 Rev. 2: Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy \|author=National Institute of Standards and Technology \|date=December 2018 \|accessdate=28 July 2023}}</ref>:

			<blockquote>Managing information system-related security and privacy risk is a complex undertaking that requires the involvement of the entire organization—from senior leaders providing the strategic vision and top-level goals and objectives for the organization, to mid-level leaders planning, executing, and managing projects, to individuals developing, implementing, operating, and maintaining the systems supporting the organization’s missions and business functions. Risk management is a holistic activity that affects every aspect of the organization, including the mission and business planning activities, the enterprise architecture, the SDLC processes, and the systems engineering activities that are integral to those system life cycle processes.</blockquote>

			As Figure 4—from the same NIST guide—notes, there are three main levels at which an organization must approach risk management activities for their information systems: the organization level, the mission/business process level, and the information system level. The arrow on the left highlights the criticality of proper communication across all three levels in order for the organization to make the most of their risk management activities. Just as IT forms the base of any software-driven business efforts, critical stakeholders in IT form the base of communication about IT risk and security requirements. Without those stakeholders' knowledge and feedback, business processes and company policy would be ill-informed. Now let's start from the top of the pyramid and head downward. Note that without strong leadership, well-crafted business goals, and management buy-in on quality, budget, and security, business processes would be a mess and IT-related efforts would be sub-par and at-risk.

			The implication with Figure 4 and NIST's guide is that effective planning and communication is critical to ensuring information systems are implemented securely during their entire life cycle. Many organizations approach this task by developing, implementing, and enforcing a [[cybersecurity]] plan, in which identifying cybersecurity requirements and objectives—i.e., [[risk assessment]] and management—is a vital component. (See the ''[[LII:Comprehensive Guide to Developing and Implementing a Cybersecurity Plan\|Comprehensive Guide to Developing and Implementing a Cybersecurity Plan]]'' for much more on this topic.)


			===3.1 Five risk categories to consider===
			In January 2021, ''Business Tech Weekly'' highlighted the biggest security challenges to organizations adopting cloud. Among them were<ref name="AntonenkoCloud21">{{cite web \|url=https://www.businesstechweekly.com/cybersecurity/data-security/cloud-computing-security-issues-and-challenges/ \|title=Cloud computing security issues and challenges \|author=Antonenko, D. \|work=Business Tech Weekly \|date=04 January 2021 \|accessdate=28 July 2023}}</ref>:

			* inadequate access control
			* insufficient contract regulation
			* unsecure software interfaces
			* low data visibility
			* delays in deleting data
			* inability to maintain regulatory compliance

			These and other related challenges are a product of the various risks of doing business in the cloud. Those risks—in the scope of business, essentially aspects of business and the environment it operates in that endanger objectives—in turn must be managed to better ensure an organization meets its goals. This requires risk management.

			Risk management is the process of identifying, evaluating, and prioritizing risks, and then developing an economical and efficient strategy for monitoring, controlling, and mitigating those risks. Whether risk management is part of an overall cybersecurity plan (as it should be) or an independent process (perhaps more common in really small organizations), it always makes sense to have strategies for managing threats and responding to opportunities, not only for the organization as a whole but also specifically for IT and software implementations.

			But what are the major risks associated with cloud computing initiatives that drive the need for risk management? And what are the potential consequences if those risks are left unchecked? Business consultancy KPMG released a 2018 report about managing risk in the cloud. In that report, author Sai Gadia identified five critical categories of risk to organizations venturing into the cloud: data security and regulatory risk, technology risk, operational risk, vendor risk, and financial risk.<ref name="GadiaHowTo18">{{cite web \|url=https://assets.kpmg.com/content/dam/kpmg/ca/pdf/2018/03/cloud-computing-risks-canada.pdf \|format=PDF \|title=How to manage five key cloud computing risks \|author=Gadia, S. \|publisher=KPMG LLP \|date=March 2018 \|accessdate=28 July 2023}}</ref>

			These five categories neatly sum up the areas of risk to apply and cloud risk assessment, but let's look at them a bit more closely.

			'''Data security and regulatory risk''': This category examines the concerns of [[data integrity]] and availability.
			* ''The potential risks'': data is leaked, lost, or becomes unavailable.
			* ''The potential consequences'': reputation loss, regulatory non-compliance, business interruptions, and loss of revenue.
			* ''The challenges associated with limiting those potential risks and consequences when embracing a cloud computing initiative'': maintaining enforcement of existing corporate security policies, maintaining regulatory compliance, managing user access effectively, managing networking across multitenancy or shared infrastructures, and gaining greater flexibility with encryption and security controls offered by the cloud service provider (CSP).
			* ''Getting around these challenges'': Organizations should "have mature data protection and regulatory compliance programs staffed with talented individuals who have sufficient authority and clear responsibilities. Such organizations also leverage leading third-party or homegrown automated tools and continuously improve their capabilities."<ref name="GadiaHowTo18" />

			'''Technology risk''': This category examines the concerns of rapid shifts in underlying technologies.
			* ''The potential risks'': cloud-specific technologies rapidly evolve, and standardization of those technologies doesn't keep up.
			* ''The potential consequences'': added costs associated with rearchitecting cloud systems, shifting data to new platforms, developing new integrations, and requiring additional training.
			* ''The challenges associated with limiting those potential risks and consequences when embracing a cloud computing initiative'': maintaining room in the budget for rearchitecting cloud applications and systems periodically, maintaining the personnel to stay engaged and focused on changes happening in the industry, and identifying tools (e.g., dashboards) that can extend the life cycle of your cloud implementation.
			* ''Getting around these challenges'': Organizations should "recognize that cloud will require the role and responsibilities of in-house IT professionals to evolve and are making the necessary investment to train individuals and encourage the adoption of innovative technology. In the process, they are also increasing alignment with the vision and business of the organization."<ref name="GadiaHowTo18" /> IT professionals should also be considering aspects of cloud such as compatibility with other CSPs as new services are added.

			'''Operational risk''': This category examines the concerns of how IT services and tasks get effectively performed.
			* ''The potential risks'': suboptimal service reliability; suboptimal service features; insufficient control over the underlying service; and theft, fires, and other natural disasters.
			* ''The potential consequences'': costly downtime, slower workflows, slower disaster recoveries, and permanent losses of vital assets.
			* ''The challenges associated with limiting those potential risks and consequences when embracing a cloud computing initiative'': maintaining room in the budget for leading technologies, maintaining room in the budget for a service that meets most if not all workflow and regulatory requirements, having the budget and knowledge to implement redundant systems (e.g., via hybrid cloud), and being able to rapidly bounce back from asset losses.
			* ''Getting around these challenges'': Organizations should "adopt the agile development methodology as well as the DevOps model for cloud deployments. Such organizations are now using the learning from pilot projects to shape the enterprise development methodologies of the future."<ref name="GadiaHowTo18" /> Additionally, they should investigate how to best cost-optimize redundant cloud storage based on access patterns, geography, etc.<ref name="WaibelCost17">{{cite journal \|title=Cost-optimized redundant data storage in the cloud \|journal=Service Oriented Computing and Applications \|name=Waibel, P.; Matt, J.; Hochreiner, C. et al. \|volume=11 \|pages=411–26 \|year=2017 \|doi=10.1007/s11761-017-0218-9}}</ref> Additionally, if the organization is responsible for localized (i.e., private cloud) assets housing critical operational data and equipment, the organization should have sufficient plans in place on how to mitigate risks from physical disasters and other threats to that data and equipment.

			'''Vendor risk''': This category examines the concerns of doing business with a CSP.
			* ''The potential risks'': vendor files for bankruptcy, is named in a lawsuit, is scrutinized by a regulatory body, or otherwise has an underlying lack of sustainability or compliance.
			* ''The potential consequences'': loss of data, loss of service, reduced service, and lack of compliance (which has its own costs to an organization).
			* ''The challenges associated with limiting those potential risks and consequences when embracing a cloud computing initiative'': knowing the deep inner workings of the CSP, knowing the financial stability of the CSP, knowing the CSP's true reputation among a wide number of other customers, and putting faith in the CSP's trust center materials.
			* ''Getting around these challenges'': Organizations should "take a long-term strategic view to manage their relationships with cloud service providers. Such companies are actively engaged and are shaping the road map of CSPs' service offerings to help accelerate their move to cloud while being offered better tools by the CSP to efficiently manage risks."<ref name="GadiaHowTo18" /> This long-term strategic view should include significant due diligence about the vendor's underlying operations, stability, and fall-back plans should they suffer a major business loss.

			'''Financial risk''': This category examines the concerns of the organization’s long-term revenues and ability to budget for cloud services.
			* ''The potential risks'': underestimating initial implementation costs, long-term service costs, long-term capital expenditure carry-over (if any), and long-term business revenues.
			* ''The potential consequences'': cost overruns, layoffs, budget cut-backs, and detrimental scaling back of necessary services.
			* ''The challenges associated with limiting those potential risks and consequences when embracing a cloud computing initiative'': finding and retaining experienced and knowledgeable staff capable of budgeting future (and changing) cloud costs, as well as managing the financial activities of the organization.
			* ''Getting around these challenges'': Organizations should “assign individuals with the responsibility for budgeting, tracking, and managing cloud costs. Such organizations are also making use of advanced third-party analytical tools available to manage cloud costs.”<ref name="GadiaHowTo18" /> Estimating those costs can be challenging, particularly in industries where high-throughput data is being created and managed. As such, negotiating a special agreement with the CSP may be of value.<ref name="NavaleCloud18">{{cite journal \|title=Cloud computing applications for biomedical science: A perspective \|journal=PLoS Computational Biology \|author=Navale, V.; Bourne, P.E. \|volume=14 \|issue=6 \|at=e1006144 \|year=2018 \|doi=10.1371/journal.pcbi.1006144 \|pmid=29902176 \|pmc=PMC6002019}}</ref> Also, ensure the organization is considering costs associated with contract modifications and cancellation fees.

			When identifying risks associated with doing business in the cloud, most likely you'll be able to fit them into one of these five categories. As indicated above, potential consequences come with potential risks, and you'll want to identify those consequences. Of course, it's not a simple matter of addressing those risks and consequences; they come with their own challenges. Identifying risks and consequences, and the challenges surrounding and limiting them, are all part of risk management. Finally, after identifying risks, consider the usefulness of an external review of those risks to ensure your organization hasn't missed anything significant.<ref name="DeloitteFFIEC20">{{cite web \|url=https://www2.deloitte.com/content/dam/Deloitte/us/Documents/financial-services/cloud-security-for-FSI.pdf \|format=PDF \|title=FFIEC statement on risk management for cloud computing services \|author=Bhat, V.; Kapur, S.; Hodgkinson, S. et al. \|publisher=Deloitte Development, LLC \|date=2020 \|accessdate=28 July 2023}}</ref>

			But how does an organization successfully go through the risk management process? That's best accomplished with the aid of one or more risk management and cybersecurity frameworks.

Shawndouglas: Replaced content with "
TOC
{{ombox | type = notice | style = width: 960px; | text = This is sublevel18 of my sandbox, where I play with features and..."

2021-09-06T13:07:55Z

Replaced content with "<div class="nonumtoc">__TOC__</div> {{ombox | type = notice | style = width: 960px; | text = This is sublevel18 of my sandbox, where I play with features and..."

Show changes

Shawndouglas at 18:10, 19 September 2019

2019-09-19T18:10:55Z

Show changes

Shawndouglas at 18:05, 17 September 2019

2019-09-17T18:05:35Z

← Older revision		Revision as of 18:05, 17 September 2019
Line 3:		Line 3:
	\| type = notice		\| type = notice
	\| style = width: 960px;		\| style = width: 960px;
	\| text = This is ~~sublevel17~~ of my sandbox, where I play with features and test MediaWiki code. If you wish to leave a comment for me, please see [[User_talk:Shawndouglas\|my discussion page]] instead.<p></p>		\| text = This is sublevel18 of my sandbox, where I play with features and test MediaWiki code. If you wish to leave a comment for me, please see [[User_talk:Shawndouglas\|my discussion page]] instead.<p></p>
	}}		}}

Shawndouglas at 18:04, 17 September 2019

2019-09-17T18:04:15Z

← Older revision		Revision as of 18:04, 17 September 2019
Line 140:		Line 140:
	\|}		\|}

	==24. Instrument Data Systems Functions==		==25. Instrument Data Systems Functions==
	{\|		{\|
	\| STYLE="vertical-align:top;"\|		\| STYLE="vertical-align:top;"\|

Shawndouglas at 18:03, 17 September 2019

2019-09-17T18:03:46Z

← Older revision		Revision as of 18:03, 17 September 2019
Line 136:		Line 136:
	\| style="padding:5px; width:500px;" \|[https://www.law.cornell.edu/cfr/text/45/170.315 45 CFR Part 170.315 (g-7–g-9)]		\| style="padding:5px; width:500px;" \|[https://www.law.cornell.edu/cfr/text/45/170.315 45 CFR Part 170.315 (g-7–g-9)]
	\| style="background-color:white;" \|'''24.22''' The EHR module should include an application programming interface (API) that demonstrates the EHR's ability to uniquely identify a patient and corresponding ID/token in a received records or data category request in order to accurately and securely meet the request for that patient's data. The API should be well documented.		\| style="background-color:white;" \|'''24.22''' The EHR module should include an application programming interface (API) that demonstrates the EHR's ability to uniquely identify a patient and corresponding ID/token in a received records or data category request in order to accurately and securely meet the request for that patient's data. The API should be well documented.
			\|-
			\|}
			\|}

			==24. Instrument Data Systems Functions==
			{\|
			\| STYLE="vertical-align:top;"\|
			{\| class="wikitable collapsible" border="1" cellpadding="10" cellspacing="0"
			\|-
			! colspan="2" style="text-align:left; padding-left:20px; padding-top:10px; padding-bottom:10px;"\|
			\|-
			! style="color:brown; background-color:#ffffee; width:500px;"\| Regulation, Specification, or Guidance
			! style="color:brown; background-color:#ffffee; width:700px;"\| Requirement
			\|-
			\| style="padding:5px; width:500px;" \|[https://www.astm.org/Standards/E1578.htm ASTM E1578-18 E-12-1]
			\| style="background-color:white;" \|'''25.1''' The system should be able to use an application programming interface or web services to communicate with instrument data systems.
			\|-
			\| style="padding:5px; width:500px;" \|[https://www.astm.org/Standards/E1578.htm ASTM E1578-18 E-12-2]
			\| style="background-color:white;" \|'''25.2''' The system should be capable of sending samples and test orders to instrument data systems.
			\|-
			\| style="padding:5px; width:500px;" \|[https://www.astm.org/Standards/E1578.htm ASTM E1578-18 E-12-3]<br />[https://www.epa.gov/sites/production/files/documents/erln_lab_requirements.pdf EPA ERLN Laboratory Requirements 4.9.16]
			\| style="background-color:white;" \|'''25.3''' The system should be capable of sending samples and test orders to instrument data systems.
			\|-
			\| style="padding:5px; width:500px;" \|[https://www.astm.org/Standards/E1578.htm ASTM E1578-18 E-12-4]
			\| style="background-color:white;" \|'''25.4''' The system should be capable of generically parsing instrument data to extract important sample details and results.
	\|-		\|-
	\|}		\|}
	\|}		\|}

Shawndouglas at 17:56, 17 September 2019

2019-09-17T17:56:21Z

← Older revision		Revision as of 17:56, 17 September 2019
Line 57:		Line 57:
	\| style="padding:5px; width:500px;" \|[https://www.law.cornell.edu/cfr/text/45/164.308 45 CFR Part 164.308]<br />[https://www.astm.org/Standards/E1578.htm ASTM E1578-18 E-11-9]		\| style="padding:5px; width:500px;" \|[https://www.law.cornell.edu/cfr/text/45/164.308 45 CFR Part 164.308]<br />[https://www.astm.org/Standards/E1578.htm ASTM E1578-18 E-11-9]
	\| style="background-color:white;" \|'''23.9''' The SDMS shall record an audit trail for each and every record created and modified, using version control.		\| style="background-color:white;" \|'''23.9''' The SDMS shall record an audit trail for each and every record created and modified, using version control.
			\|-
			\|}
			\|}

			==24. Health Information Technology==
			{\|
			\| STYLE="vertical-align:top;"\|
			{\| class="wikitable collapsible" border="1" cellpadding="10" cellspacing="0"
			\|-
			! colspan="2" style="text-align:left; padding-left:20px; padding-top:10px; padding-bottom:10px;"\|
			\|-
			! style="color:brown; background-color:#ffffee; width:500px;"\| Regulation, Specification, or Guidance
			! style="color:brown; background-color:#ffffee; width:700px;"\| Requirement
			\|-
			\| style="padding:5px; width:500px;" \|[https://www.law.cornell.edu/cfr/text/45/170.315 45 CFR Part 170.315 (a-1–a-4)]
			\| style="background-color:white;" \|'''24.1''' The electronic health record (EHR) module should provide computerized provider order entry (CPOE) functionality for medication orders, laboratory orders, and diagnostic imaging, including making checks for potential drug-drug and drug-allergy interactions.
			\|-
			\| style="padding:5px; width:500px;" \|[https://www.law.cornell.edu/cfr/text/45/170.315 45 CFR Part 170.315 (a-5)]<br />[https://www.law.cornell.edu/cfr/text/45/170.315 45 CFR Part 170.315 (a-11–a-12)]<br />[https://www.law.cornell.edu/cfr/text/45/170.315 45 CFR Part 170.315 (a-15)]
			\| style="background-color:white;" \|'''24.2''' The EHR module should allow authorized personnel to record, change, and access patient demographic data, including, but not limited to, race and ethnicity, patient's preferred language, birth sex, current sex, sexual orientation, gender identity, birth date, smoking status, alcohol use, family health history, psychological aspects, social aspects, and behavioral aspects.
			\|-
			\| style="padding:5px; width:500px;" \|[https://www.law.cornell.edu/cfr/text/45/170.315 45 CFR Part 170.315 (a-6–a-8)]<br />[https://www.law.cornell.edu/cfr/text/45/170.315 45 CFR Part 170.315 (a-10)]<br />[https://www.law.cornell.edu/cfr/text/45/170.315 45 CFR Part 170.315 (a-14)]
			\| style="background-color:white;" \|'''24.3''' The EHR module should allow authorized personnel to record, change, and access a patient's active problem list, medication list, medication allergy list, preferred drug list, and implantable device list, incorporating, where appropriate, at a minimum the SNOMED CT nomenclature standard.
			\|-
			\| style="padding:5px; width:500px;" \|[https://www.law.cornell.edu/cfr/text/45/170.315 45 CFR Part 170.315 (a-19)]
			\| style="background-color:white;" \|'''24.4''' The EHR module should incorporate configurable, role-based clinical decision support tools capable of allowing authorized personnel to trigger electronic interventions based on liked reference information standardized to Health Level 7 (HL7) Version 3 implementation guides. The reference information should be sourced.
			\|-
			\| style="padding:5px; width:500px;" \|[https://www.law.cornell.edu/cfr/text/45/170.315 45 CFR Part 170.315 (a-13)]
			\| style="background-color:white;" \|'''24.5''' The EHR module should be able to identify education resources specific to a patient's active problem and medication lists. The educational resources should be standardized to Health Level 7 (HL7) Version 3 implementation guides.
			\|-
			\| style="padding:5px; width:500px;" \|[https://www.law.cornell.edu/cfr/text/45/170.315 45 CFR Part 170.315 (b-1–b-2; b-4–b-5)]
			\| style="background-color:white;" \|'''24.6''' The EHR module should allow authorized personnel to create, view, send, and receive transition of care or referral summaries in such a way that the summary is properly formatted, matched to the correct patient, and reconciled according to the standards and protocols outlined in 45 CFR Part 170.315 (b-1), (b-2), (b-4), and (b-5).
			\|-
			\| style="padding:5px; width:500px;" \|[https://www.law.cornell.edu/cfr/text/45/170.315 45 CFR Part 170.315 (b-3)]
			\| style="background-color:white;" \|'''24.7''' The EHR module should allow authorized personnel to conduct electronic prescribing actions such as creating, changing, cancelling, and refilling prescriptions, incorporating at least the RxNorm and NCPDP SCRIPT standards.
			\|-
			\| style="padding:5px; width:500px;" \|[https://www.law.cornell.edu/cfr/text/45/170.315 45 CFR Part 170.315 (b-6)]
			\| style="background-color:white;" \|'''24.8''' The EHR module should allow authorized personnel to configure, create, and store data exports, incorporating at least HL7 Version 3 implementation standards, as well as SNOMED CT and ICD-9 standards.
			\|-
			\| style="padding:5px; width:500px;" \|[https://www.law.cornell.edu/cfr/text/45/170.315 45 CFR Part 170.315 (b-7–b-8)]
			\| style="background-color:white;" \|'''24.9''' The EHR module should allow for the secure creation, sending, and receipt of restricted summary records, incorporating HL7 Version 3 implementation standards.
			\|-
			\| style="padding:5px; width:500px;" \|[https://www.law.cornell.edu/cfr/text/45/170.315 45 CFR Part 170.315 (b-9)]
			\| style="background-color:white;" \|'''24.10''' The EHR module should allow authorized personnel to create, record, change, access, and receive care plan information, incorporating HL7 Version 3 implementation standards.
			\|-
			\| style="padding:5px; width:500px;" \|[https://www.law.cornell.edu/cfr/text/45/170.315 45 CFR Part 170.315 (c)]
			\| style="background-color:white;" \|'''24.11''' The EHR module should provide a means to record, calculate, import, export, filter, and report on clinical quality measures according to the standards outlined in 45 CFR Part 170.315 (c).
			\|-
			\| style="padding:5px; width:500px;" \|[https://www.law.cornell.edu/cfr/text/45/170.315 45 CFR Part 170.315 (d)]
			\| style="background-color:white;" \|'''24.12''' The EHR module shall provide security and access controls for protecting stored data.
			\|-
			\| style="padding:5px; width:500px;" \|[https://www.law.cornell.edu/cfr/text/45/170.315 45 CFR Part 170.315 (d)]
			\| style="background-color:white;" \|'''24.13''' The EHR module shall record an audit trail for each and every record created and modified, using version control.
			\|-
			\| style="padding:5px; width:500px;" \|[https://www.law.cornell.edu/cfr/text/45/170.315 45 CFR Part 170.315 (d-7)]
			\| style="background-color:white;" \|'''24.14''' The EHR module shall either encrypt electronic health information on end-user devices after use of the technology on the device stops or prevent electronic health information from being stored on end-user devices after use of the technology on the device stops.
			\|-
			\| style="padding:5px; width:500px;" \|[https://www.law.cornell.edu/cfr/text/45/170.315 45 CFR Part 170.315 (d-8)]
			\| style="background-color:white;" \|'''24.15''' The EHR module shall ensure that electronically exchanged health information has not been altered during the transfer process, using at least a hashing algorithm secured to SHA-2 or better.
			\|-
			\| style="padding:5px; width:500px;" \|[https://www.law.cornell.edu/cfr/text/45/170.315 45 CFR Part 170.315 (d-11)]
			\| style="background-color:white;" \|'''24.16''' The EHR module should be capable of recording patient disclosures made for treatment, payment, and health care operations.
			\|-
			\| style="padding:5px; width:500px;" \|[https://www.law.cornell.edu/cfr/text/45/170.315 45 CFR Part 170.315 (e-1)]
			\| style="background-color:white;" \|'''24.17''' The EHR module should provide a means for patients and their authorized representatives to view, download, and transmit their personal health information and activity history log from the EHR via an internet-based technology, using the standards outlined in 45 CFR Part 170.315 (e-1).
			\|-
			\| style="padding:5px; width:500px;" \|[https://www.law.cornell.edu/cfr/text/45/170.315 45 CFR Part 170.315 (e-2–e-3)]
			\| style="background-color:white;" \|'''24.18''' The EHR module should provide a means for authorized users to securely send messages to and receive messages from patients, at the same time allowing for the recording, accessing, and linking of information shared by the patient electronically (as well as directly).
			\|-
			\| style="padding:5px; width:500px;" \|[https://www.law.cornell.edu/cfr/text/45/170.315 45 CFR Part 170.315 (f)]
			\| style="background-color:white;" \|'''24.19''' The EHR module should allow vital patient information as it relates to public health to be transmitted to immunization registries, cancer registries, and public health agencies, as well as be accessed after the fact. This includes, but is not limited to, immunization history, surveillance information, laboratory test results, cancer case information, case reports, antimicrobial reporting, and health care survey information.
			\|-
			\| style="padding:5px; width:500px;" \|[https://www.law.cornell.edu/cfr/text/45/170.315 45 CFR Part 170.315 (g-3–g-5)]
			\| style="background-color:white;" \|'''24.20''' The EHR developer should use user-centered and accessibility-centered design processes for creating and testing the EHR's functionality. A quality management system should be used during these processes.
			\|-
			\| style="padding:5px; width:500px;" \|[https://www.law.cornell.edu/cfr/text/45/170.315 45 CFR Part 170.315 (g-6)]
			\| style="background-color:white;" \|'''24.21''' The EHR module's use of clinical document architecture (CDA) should be demonstrated and verified for conformance to the standards identified in 45 CFR Part 170.315 (g-6).
			\|-
			\| style="padding:5px; width:500px;" \|[https://www.law.cornell.edu/cfr/text/45/170.315 45 CFR Part 170.315 (g-7–g-9)]
			\| style="background-color:white;" \|'''24.22''' The EHR module should include an application programming interface (API) that demonstrates the EHR's ability to uniquely identify a patient and corresponding ID/token in a received records or data category request in order to accurately and securely meet the request for that patient's data. The API should be well documented.
	\|-		\|-
	\|}		\|}
	\|}		\|}

Shawndouglas: Created page with "
TOC
{{ombox | type = notice | style = width: 960px; | text = This is sublevel17 of my sandbox, where I play with features and tes..."

2019-09-17T17:32:51Z

Created page with "<div class="nonumtoc">__TOC__</div> {{ombox | type = notice | style = width: 960px; | text = This is sublevel17 of my sandbox, where I play with features and tes..."

New page

<div class="nonumtoc">__TOC__</div>
{{ombox
| type = notice
| style = width: 960px;
| text = This is sublevel17 of my sandbox, where I play with features and test MediaWiki code. If you wish to leave a comment for me, please see [[User_talk:Shawndouglas|my discussion page]] instead.<p></p>
}}

==Sandbox begins below==

==23. Scientific Data Management==
{|
| STYLE="vertical-align:top;"|
{| class="wikitable collapsible" border="1" cellpadding="10" cellspacing="0"
|-
! colspan="2" style="text-align:left; padding-left:20px; padding-top:10px; padding-bottom:10px;"|
|-
! style="color:brown; background-color:#ffffee; width:500px;"| Regulation, Specification, or Guidance
! style="color:brown; background-color:#ffffee; width:700px;"| Requirement
|-
| style="padding:5px; width:500px;" |
[https://www.astm.org/Standards/E1578.htm ASTM E1578-18 E-11-1]<br />
[https://www.epa.gov/sites/production/files/documents/erln_lab_requirements.pdf EPA ERLN Laboratory Requirements 4.3.4.1]<br />
[https://www.epa.gov/sites/production/files/documents/erln_lab_requirements.pdf EPA ERLN Laboratory Requirements 4.8.9]<br />
[https://www.epa.gov/sites/production/files/documents/erln_lab_requirements.pdf EPA ERLN Laboratory Requirements 4.9.9]
| style="background-color:white;" |'''23.1''' The system shall capture raw instrument data and metadata either as an electronic file or directly via RS-232 or TCP/IP communication.
|-
| style="padding:5px; width:500px;" |[https://www.astm.org/Standards/E1578.htm ASTM E1578-18 E-11-2]
| style="background-color:white;" |'''23.2''' The scientific data management system (SDMS) should provide a checksum verification of source and destination data and store that verification data in a secure server with controlled access.
|-
| style="padding:5px; width:500px;" |
[https://www.astm.org/Standards/E1578.htm ASTM E1578-18 E-11-1]<br />
[https://www.epa.gov/sites/production/files/documents/erln_lab_requirements.pdf EPA ERLN Laboratory Requirements 4.3.4.1]<br />
[https://www.epa.gov/sites/production/files/documents/erln_lab_requirements.pdf EPA ERLN Laboratory Requirements 4.8.9]<br />
[https://www.epa.gov/sites/production/files/documents/erln_lab_requirements.pdf EPA ERLN Laboratory Requirements 4.9.9]
| style="background-color:white;" |'''23.3''' The system shall store metadata related to raw instrument data in a database in such a way that the original data generated by instruments for specific samples and tests is easy to retrieve.
|-
| style="padding:5px; width:500px;" |[https://www.astm.org/Standards/E1578.htm ASTM E1578-18 E-11-4]
| style="background-color:white;" |'''23.4''' The system should be capable of capturing a complete and readable copy of original data and any previous versions of modified data in order to maintain the integrity of that data.
|-
| style="padding:5px; width:500px;" |
[https://www.aavld.org/accreditation-requirements-page AAVLD AAVLD Requirements for an AVMDL Sec. 4.10.2.3]<br />
[https://www.astm.org/Standards/E1578.htm ASTM E1578-18 E-11-5]<br />
[https://www.epa.gov/sites/production/files/documents/erln_lab_requirements.pdf EPA ERLN Laboratory Requirements 4.3.4.1]<br />
[https://www.epa.gov/sites/production/files/documents/erln_lab_requirements.pdf EPA ERLN Laboratory Requirements 4.8.9]<br />
[https://www.epa.gov/sites/production/files/documents/erln_lab_requirements.pdf EPA ERLN Laboratory Requirements 4.9.9]
| style="background-color:white;" |'''23.5''' The system should secure raw data such that it can't be deleted and provide version control when data is modified by any user or specific software.
|-
| style="padding:5px; width:500px;" |[https://www.astm.org/Standards/E1578.htm ASTM E1578-18 E-11-6]
| style="background-color:white;" |'''23.6''' The SDMS should provide tools for helping a laboratory achieve the U.S. Food and Drug Administration's defined ALCOA principles.
|-
| style="padding:5px; width:500px;" |[https://www.astm.org/Standards/E1578.htm ASTM E1578-18 E-11-7]
| style="background-color:white;" |'''23.7''' The SDMS shall provide security and access controls for protecting stored data.
|-
| style="padding:5px; width:500px;" |[https://www.astm.org/Standards/E1578.htm ASTM E1578-18 E-11-8]
| style="background-color:white;" |'''23.8''' The SDMS shall record an audit trail for each and every record created and modified, using version control.
|-
| style="padding:5px; width:500px;" |[https://www.law.cornell.edu/cfr/text/45/164.308 45 CFR Part 164.308]<br />[https://www.astm.org/Standards/E1578.htm ASTM E1578-18 E-11-9]
| style="background-color:white;" |'''23.9''' The SDMS shall record an audit trail for each and every record created and modified, using version control.
|-
|}
|}

User:Shawndouglas/sandbox/sublevel18 - Revision history

Shawndouglas: Replaced content with "__TOC__ {{ombox | type = notice | style = width: 960px; | text = This is sublevel18 of my sandbox, where I play with features and..."

Shawndouglas at 18:58, 15 August 2023

Shawndouglas at 17:28, 26 July 2023

Shawndouglas: Replaced content with "__TOC__ {{ombox | type = notice | style = width: 960px; | text = This is sublevel18 of my sandbox, where I play with features and..."

Shawndouglas at 18:10, 19 September 2019

Shawndouglas at 18:05, 17 September 2019

Shawndouglas at 18:04, 17 September 2019

Shawndouglas at 18:03, 17 September 2019

Shawndouglas at 17:56, 17 September 2019

Shawndouglas: Created page with "__TOC__ {{ombox | type = notice | style = width: 960px; | text = This is sublevel17 of my sandbox, where I play with features and tes..."

Shawndouglas: Replaced content with "
TOC
{{ombox | type = notice | style = width: 960px; | text = This is sublevel18 of my sandbox, where I play with features and..."

Shawndouglas: Replaced content with "
TOC
{{ombox | type = notice | style = width: 960px; | text = This is sublevel18 of my sandbox, where I play with features and..."

Shawndouglas: Created page with "
TOC
{{ombox | type = notice | style = width: 960px; | text = This is sublevel17 of my sandbox, where I play with features and tes..."