|
|
(112 intermediate revisions by the same user not shown) |
Line 1: |
Line 1: |
| To be fair, the question of which regulations and standards affect how an organization implements cybersecurity is a most difficult one to answer. Not only do related regulations and standards vary by industry, they also vary by geography, complexity, and ease of implementation. Let's turn to the example of data retention requirements for businesses. Consider this software system requirements statement:
| |
|
| |
|
| <blockquote>''The system shall have a mechanism to securely retain data in the system for a specific time period and enable protections that ensure the accurate and ready retrieval of that data throughout the records retention period.''</blockquote>
| | ==The laws themselves== |
|
| |
|
| Through recent updates to LIMSpec, the following national and international regulations, standards, and guidance (Table 1) that tie into data retention and the protection of that retained data have been found (and that list will certainly continue to grow):
| | ===1. Federal Telecommunications Act of 1996, Section 255 ([https://www.law.cornell.edu/uscode/text/47/255 47 U.S.C. § 255 - Access by persons with disabilities])=== |
|
| |
|
| {|
| | <blockquote>'''(b) Manufacturing''' |
| | STYLE="vertical-align:top;"|
| | A manufacturer of telecommunications equipment or customer premises equipment shall ensure that the equipment is designed, developed, and fabricated to be accessible to and usable by individuals with disabilities, if readily achievable. |
| {| class="wikitable" border="1" cellpadding="5" cellspacing="0" width="100%"
| |
| |-
| |
| | style="background-color:white; padding-left:10px; padding-right:10px;" colspan="2"|'''Table 1.''' Regulations, standards, and guidance affecting data retention and the security of retained data
| |
| |-
| |
| |-
| |
| | style="background-color:white; padding-left:10px; padding-right:10px;"|
| |
| [https://www.law.cornell.edu/cfr/text/7/331.17 7 CFR Part 331.17 (c)]<br />
| |
| [https://www.law.cornell.edu/cfr/text/9/121.17 9 CFR Part 121.17 (c)]<br />
| |
| [https://www.law.cornell.edu/cfr/text/21/11.10 21 CFR Part 11.10 (c)]<br />
| |
| [https://www.law.cornell.edu/cfr/text/21/58.195 21 CFR Part 58.195]<br />
| |
| [https://www.law.cornell.edu/cfr/text/21/211.180 21 CFR Part 211.180]<br />
| |
| [https://www.law.cornell.edu/cfr/text/21/211.110 21 CFR Part 212.110 (c)]<br />
| |
| [https://www.law.cornell.edu/cfr/text/21/225.42 21 CFR Part 225.42 (b-8)]<br />
| |
| [https://www.law.cornell.edu/cfr/text/21/225.58 21 CFR Part 225.58 (c–d)]<br />
| |
| [https://www.law.cornell.edu/cfr/text/21/225.102 21 CFR Part 225.102]<br />
| |
| [https://www.law.cornell.edu/cfr/text/21/225.110 21 CFR Part 225.110]<br />
| |
| [https://www.law.cornell.edu/cfr/text/21/225.158 21 CFR Part 225.158]<br />
| |
| [https://www.law.cornell.edu/cfr/text/21/225.202 21 CFR Part 225.202]<br />
| |
| [https://www.law.cornell.edu/cfr/text/21/226.42 21 CFR Part 226.42 (a)]<br />
| |
| [https://www.law.cornell.edu/cfr/text/21/226.58 21 CFR Part 226.58 (f)]<br />
| |
| [https://www.law.cornell.edu/cfr/text/21/226.102 21 CFR Part 226.102]<br />
| |
| [https://www.law.cornell.edu/cfr/text/21/226.115 21 CFR Part 226.115]<br />
| |
| [https://www.law.cornell.edu/cfr/text/21/312.57 21 CFR Part 312.57]<br />
| |
| [https://www.law.cornell.edu/cfr/text/21/312.62 21 CFR Part 312.62]<br />
| |
| [https://www.law.cornell.edu/cfr/text/21/606.160 21 CFR Part 606.160 (d)]<br />
| |
| [https://www.law.cornell.edu/cfr/text/21/812.140 21 CFR Part 812.140 (d)]<br />
| |
| [https://www.law.cornell.edu/cfr/text/21/820.180 21 CFR Part 820.180 (b)]<br />
| |
| [https://www.law.cornell.edu/cfr/text/29/1910.1030 29 CFR Part 1910.1030 (h-2)]<br />
| |
| [https://www.law.cornell.edu/cfr/text/40/141.33 40 CFR Part 141.33]<br />
| |
| [https://www.law.cornell.edu/cfr/text/40/141.722 40 CFR Part 141.722]<br />
| |
| [https://www.law.cornell.edu/cfr/text/40/part-704/subpart-A 40 CFR Part 704 Subpart A]<br />
| |
| [https://www.law.cornell.edu/cfr/text/40/717.15 40 CFR Part 717.15 (d)]<br />
| |
| [https://www.law.cornell.edu/cfr/text/42/73.17 42 CFR Part 73.17 (c)]<br />
| |
| [https://www.law.cornell.edu/cfr/text/42/493.1105 42 CFR Part 493.1105]<br />
| |
| [https://www.law.cornell.edu/cfr/text/42/493.1283 42 CFR Part 493.1283]<br />
| |
| [https://www.law.cornell.edu/cfr/text/45/164.105 45 CFR Part 164.105]<br />
| |
| [https://www.law.cornell.edu/cfr/text/45/164.316 45 CFR Part 164.316]<br />
| |
| [https://www.law.cornell.edu/cfr/text/45/164.530 45 CFR Part 164.530]<br />
| |
| | style="background-color:white; padding-left:10px; padding-right:10px;"|
| |
| [https://www.aafco.org/Publications/QA-QC-Guidelines-for-Feed-Laboratories AAFCO QA/QC Guidelines for Feed Laboratories Sec. 2.4.4 or 3.1]<br />
| |
| [https://www.aavld.org/accreditation-requirements-page AAVLD Requirements for an AVMDL Sec. 4.10.1.2]<br />
| |
| [https://www.aavld.org/accreditation-requirements-page AAVLD Requirements for an AVMDL Sec. 4.10.2.1]<br />
| |
| [https://www.aavld.org/accreditation-requirements-page AAVLD Requirements for an AVMDL Sec. 5.4.3.2]<br />
| |
| [http://www.abft.org/files/ABFT_LAP_Standards_May_31_2013.pdf ABFT Accreditation Manual Sec. E-33]<br />
| |
| [https://www.aihaaccreditedlabs.org/Policies/Pages/default.aspx AIHA-LAP Policies 2018 2A.7.5.1]<br />
| |
| [http://des.wa.gov/sites/default/files/public/documents/About/1063/RFP/Add7_Item4ASCLD.pdf ASCLD/LAB Supp. Reqs. for the Accreditation of Forensic Science Testing Laboratories 4.14.1.2 and 4.15.1.2]<br />
| |
| [http://des.wa.gov/sites/default/files/public/documents/About/1063/RFP/Add7_Item4ASCLD.pdf ASCLD/LAB Supp. Reqs. for the Accreditation of Forensic Science Testing Laboratories 5.9.3.6 and 5.9.7]<br />
| |
| [https://www.astm.org/Standards/E1578.htm ASTM E1578-18 E-17-4]<br />
| |
| [https://www.fbi.gov/services/cjis/cjis-security-policy-resource-center CJIS Security Policy 5.3.4]<br />
| |
| [https://www.fbi.gov/services/cjis/cjis-security-policy-resource-center CJIS Security Policy 5.4.6–7]<br />
| |
| [https://www.fbi.gov/services/cjis/cjis-security-policy-resource-center CJIS Security Policy 5.5.2.1]<br />
| |
| [https://ec.europa.eu/health/sites/health/files/files/eudralex/vol-4/annex11_01-2011_en.pdf E.U. Annex 11-7.1]<br />
| |
| [https://ec.europa.eu/health/sites/health/files/files/eudralex/vol-1/dir_2003_94/dir_2003_94_en.pdf E.U. Commission Directive 2003/94/EC Article 9.1]<br />
| |
| [https://ec.europa.eu/health/sites/health/files/files/eudralex/vol-1/dir_2003_94/dir_2003_94_en.pdf E.U. Commission Directive 2003/94/EC Article 11.4]<br />
| |
| [https://nepis.epa.gov/Exe/ZyPDF.cgi?Dockey=30006MXP.PDF EPA 815-R-05-004 Chap. III, Sec. 15]<br />
| |
| [https://nepis.epa.gov/Exe/ZyPDF.cgi?Dockey=30006MXP.PDF EPA 815-R-05-004 Chap. IV, Sec. 8]<br />
| |
| [https://www.epa.gov/sites/production/files/documents/erln_lab_requirements.pdf EPA ERLN Laboratory Requirements 4.9.18]<br />
| |
| [https://www.epa.gov/sites/production/files/documents/erln_lab_requirements.pdf EPA ERLN Laboratory Requirements 4.11.17]<br />
| |
| [https://www.epa.gov/quality/guidance-quality-assurance-project-plans-epa-qag-5 EPA QA/G-5 2.1.9]<br />
| |
| [https://www.iso.org/standard/56115.html ISO 15189:2012 4.3]<br />
| |
| [https://www.iso.org/standard/66912.html ISO/IEC 17025:2017 8.4.2]<br />
| |
| [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf NIST 800-53, Rev. 4, AT-4]<br />
| |
| [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf NIST 800-53, Rev. 4, AU-11 and AU-11(1)]<br />
| |
| [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf NIST 800-53, Rev. 4, SI-12]<br />
| |
| [http://www.oecd.org/chemicalsafety/testing/oecdseriesonprinciplesofgoodlaboratorypracticeglpandcompliancemonitoring.htm OECD GLP Principles 10]<br />
| |
| [https://www.ams.usda.gov/datasets/pdp/pdp-standard-operating-procedures USDA Administrative Procedures for the PDP 5.4]<br />
| |
| [https://www.ams.usda.gov/datasets/pdp/pdp-standard-operating-procedures USDA Sampling Procedures for PDP 6.5]<br />
| |
| [https://extranet.who.int/prequal/content/who-technical-report-series WHO Technical Report Series, #986, Annex 2, 15.8–9]
| |
| |-
| |
| |}
| |
| |}
| |
|
| |
|
| You'll notice many nods to U.S. Code of Federal Regulations (CFR), as well as E.U. law, agency requirements, accreditation requirements, standards, and guidelines for just this one system specification and security control. Additionally, there are surely other entities not listed in Table 1 that demand this requirement out of information system users. This example illustrates the complexity of making a complete and accurate list of regulations, standards, guidance, and other bodies of work demanding data protection from organizations.
| | '''(c) Telecommunications services''' |
|
| |
|
| That said, other types of legislation and standards relevant to cybersecurity stand out. Examples of legislation that mandate cybersecurity action include 23 NYCRR 500, the Federal Information Systems Management Act (FISMA), the General Data Protection Regulation (GDPR), the Gramm-Leach-Bliley Act, the Health Insurance Portability and Accountability Act of 1996 (HIPAA), IC Directive 503, the Personal Information Protection and Electronic Documents Act (PIPEDA), and the Sarbanes Oxley Act.<ref name="AulakhCISOS19">{{cite web |url=https://ignyteplatform.com/top-30-security-frameworks-2019/ |title=CISOS Ultimate Guide for Top 30 Security Control Frameworks - 2019 |author=Aulakh, M. |work=Ignyte Assurance Platform |publisher=Mafazo LLC |date=25 February 2019 |accessdate=23 July 2020}}</ref> Of standards not mentioned in Table 1, ANSI UL 2900-2-1 for networked medical devices, IEEE 1686-2013 for intelligent electronic devices, and ISO/IEC 27032:2012 for cybersecurity are also representative examples of standard-based efforts to improve cybersecurity in numerous industries.<ref name="Cleaveland10Key18">{{cite web |url=https://enterpriseiotinsights.com/20180924/fundamentals/10-key-private-sector-cybersecurity-standards |title=10 key private-sector cybersecurity standards |author=Cleaveland, P. |work=Enterprise IOT Insights - Fundamentals |publisher=Arden Media Company, LLC |date=24 September 2018 |accessdate=23 July 2020}}</ref>
| | A provider of telecommunications service shall ensure that the service is accessible to and usable by individuals with disabilities, if readily achievable. |
|
| |
|
| Despite the difficulty of laying out a complete picture of regulations and standards impacting cybersecurity approaches, we can confidently say a few things about those types of regulations and standards. First, the risks and consequences of poor security drive regulation and, more preferably<ref name="CiocoiuTheRole10">{{cite book |chapter=Chapter 1. The Role of Standardization in Improving the Effectiveness of Integrated Risk Management |title=Advances in Risk Management |author=Ciocoui, C.N.; Dobrea, R.C. |editor=Nota, G. |publisher=IntechOpen |year=2010 |isbn=9789535159469 |doi=10.5772/9893}}</ref><ref name="JPMorganData18">{{cite web |url=https://www.jpmorganchase.com/corporate/news/document/call-to-action.pdf |archiveurl=https://web.archive.org/web/20191214203246/https://www.jpmorganchase.com/corporate/news/document/call-to-action.pdf |format=PDF |title=Data Standardization: A Call to Action |publisher=JPMorgan Chase & Co |date=May 2018 |archivedate=14 December 2019 |accessdate=23 July 2020}}</ref>, standardization, which in turn moves the "goalposts" of cybersecurity among organizations. In the case of regulations, those organization that get caught not conforming to applicable regulations tend to suffer negative consequences, providing some incentive for them to improve organizational processes. One of the downsides of regulations is that they can at times be "imprecise" or "disconnected"<ref name="JPMorganData18" /> from what actually occurs within the organization and its information systems. Rather than compelling significant focus on regulatory conformance, cybersecurity standards may, when adopted, provide a clearer path of opportunity for organizations to instead focus on improving their cybersecurity culture and outcomes, particularly since standards are usually developed with a broader consensus of interested individuals with expertise in the field.<ref name="CiocoiuTheRole10" /> In turn, the organizations that adopt well-designed standards likely have a better chance of conforming to the regulations they must, and they'll likely have more interest in maintaining and improving the goalposts of cybersecurity.
| | '''(d) Compatibility''' |
| | Whenever the requirements of subsections (b) and (c) are not readily achievable, such a manufacturer or provider shall ensure that the equipment or service is compatible with existing peripheral devices or specialized customer premises equipment commonly used by individuals with disabilities to achieve access, if readily achievable.</blockquote> |
|
| |
|
| That's not to say that compliance with regulations and standards alone can stop critical risks in their tracks<ref name="KaplanManaging12">{{cite web |url=https://hbr.org/2012/06/managing-risks-a-new-framework |title=Managing Risks: A New Framework |author=Kaplan, R.S.; Mikes, A. |work=Harvard Business Review |date=June 2012 |accessdate=23 July 2020}}</ref>:
| | The term '''disability''' is [https://www.law.cornell.edu/uscode/text/42/12102 defined here]. You can read the full entry, but the basics are: |
|
| |
|
| <blockquote>Rules and compliance can mitigate some critical risks but not all of them. Active and cost-effective risk management requires managers to think systematically about the multiple categories of risks they face so that they can institute appropriate processes for each. These processes will neutralize their managerial bias of seeing the world as they would like it to be rather than as it actually is or could possibly become.</blockquote> | | <blockquote>'''(1) Disability''' The term “disability” means, with respect to an individual— |
| | :'''(A)''' a physical or mental impairment that substantially limits one or more major life activities of such individual; |
|
| |
|
| Second, modern cybersecurity standards frameworks and controls, which help guide organizations in developing a cybersecurity strategy, are typically harmonized with other standards and updated as business processes, technologies, cyber threats, and regulations evolve. For example, the industry-specific ''Water Sector Cybersecurity Risk Management Guidance v3.0'', which contains a set of cybersecurity controls as they relate to the water and wastewater sectors, is harmonized with the NIST Cybersecurity Framework.<ref name="AWWACyber19">{{cite web |url=https://www.awwa.org/Resources-Tools/Resource-Topics/Risk-Resilience/Cybersecurity-Guidance |title=Water Sector Cybersecurity Risk Management Guidance |author=West Yost Associates |publisher=American Water Works Association |date=04 September 2019 |accessdate=23 July 2020}}</ref> And NIST's Special Publication 800-171, Revision 2: ''Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations'' has controls mapped to ISO/IEC 27001:2013 controls.<ref name=NISTSP800-171_18">{{cite web |url=https://csrc.nist.gov/publications/detail/sp/800-171/rev-2/final |title=NIST SP 800-171, Rev. 2 Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations |work=Computer Security Resource Center |publisher=National Institute of Standards and Technology |date=February 2020 |accessdate=23 July 2020}}</ref> These and other signs point to some consolidation of thought on influential cybersecurity standards, as well as what constitutes relevant and necessary action towards preparing an organization to be more prepared for cyber threats and their potential consequences.
| | :'''(B)''' a record of such an impairment; or |
|
| |
|
| Third, when it comes to the question of what regulations are driving an organization to embrace cybersecurity, the general answer is "it's specific to each organization." While it's true that industries have their own regulations, and organizations in those industries often share the same set of challenges, additional factors such as regional requirements (e.g., the European Union General Data Protection Regulations [GDPR] and California Consumer Privacy Act [CCPA]) and even local requirements (e.g., privacy rules and guidelines, banning of specific technology in a city<ref name="WaddellCities19">{{cite web |url=https://www.axios.com/cities-data-privacy-laws-fa0be8cb-234f-4237-b670-10ad042a772e.html |title=Cities are writing privacy policies |author=Waddell, K. |work=Axios |date=29 June 2019 |accessdate=23 July 2020}}</ref>) will affect how the organization must operate. This information gathering process is a unique aspect of organizational cybersecurity planning; in the end it's up to the organization to "identify all obligatory cybersecurity requirements and controls with which it must comply."<ref name="CGIUnderstand19">{{cite web |url=https://www.cgi.com/sites/default/files/2019-08/cgi-understanding-cybersecurity-standards-white-paper.pdf |format=PDF |title=Understanding Cybersecurity Standards |publisher=CGI, Inc |date=April 2019 |accessdate=23 July 2020}}</ref> Armed with that information, the organization can integrate those identified requirements and controls with an existing baseline framework of broad and industry-specific cybersecurity controls, as well as any internal standards and control objectives specific to the organization and its policy requirements.<ref name="CGIUnderstand19" />
| | :'''(C)''' being regarded as having such an impairment (as described in paragraph (3)).</blockquote> |
|
| |
|
| ==References== | | The term '''readily achievable''' is [https://www.law.cornell.edu/uscode/text/42/12181 defined here]. It is defines as: |
| {{Reflist|colwidth=30em}}
| | |
| | <blockquote>'''(9) Readily achievable''' The term “readily achievable” means easily accomplishable and able to be carried out without much difficulty or expense. In determining whether an action is readily achievable, factors to be considered include— |
| | |
| | :'''(A)''' the nature and cost of the action needed under this chapter; |
| | :'''(B)''' the overall financial resources of the facility or facilities involved in the action; the number of persons employed at such facility; the effect on expenses and resources, or the impact otherwise of such action upon the operation of the facility; |
| | :'''(C)''' the overall financial resources of the covered entity; the overall size of the business of a covered entity with respect to the number of its employees; the number, type, and location of its facilities; and |
| | :'''(D)''' the type of operation or operations of the covered entity, including the composition, structure, and functions of the workforce of such entity; the geographic separateness, administrative or fiscal relationship of the facility or facilities in question to the covered entity.</blockquote> |
| | |
| | ===2. Rehabilitation Act of 1973, Section 508, amended ([https://www.law.cornell.edu/uscode/text/29/794d 29 U.S.C. 794d] - Electronic and information technology)=== |
| | |
| | There's a government website dedicated to Section 508: [https://www.section508.gov/ https://www.section508.gov/] The related laws and polices can be [https://www.section508.gov/manage/laws-and-policies/ found here]. The intro states (italics emphasis mine): |
| | |
| | <blockquote>In 1998, Congress amended the Rehabilitation Act of 1973 to require Federal agencies to make their electronic and information technology (EIT) accessible to people with disabilities. The law (29 U.S.C § 794 (d)) ''applies to all Federal agencies when they develop, procure, maintain, or use electronic and information technology''. Under Section 508, agencies must give ''disabled employees and members of the public'' access to information comparable to the access available to others. |
| | |
| | The [https://www.access-board.gov/ U.S. Access Board] is responsible for developing Information and Communication Technology (ICT) accessibility ''standards'' to ''incorporate into regulations that govern Federal procurement practices.'' On January 18, 2017, the Access Board issued a final rule that updated accessibility requirements covered by Section 508, and refreshed guidelines for telecommunications equipment subject to Section 255 of the Communications Act. The final rule went into effect on January 18, 2018. |
| | |
| | The rule updated and reorganized the Section 508 Standards and Section 255 Guidelines ''in response to market trends and innovations in technology.'' The refresh also harmonized these requirements with other guidelines and standards both in the U.S. and abroad, including standards issued by the European Commission, ''and with the World Wide Web Consortium (W3C) Web Content Accessibility Guidelines (WCAG 2.0), a globally recognized voluntary consensus standard for web content and ICT.''</blockquote> |
| | |
| | In discussing ICT, the U.S. Access Board [https://www.access-board.gov/ict/#b-summary-of-key-provisions summarized the key provisions] as such: |
| | |
| | <blockquote>The Revised 508 Standards and 255 Guidelines replace the current product-based regulatory approach with an approach based on ICT functions. The revised technical requirements, which are organized along the lines of ICT functionality, provide requirements to ensure that covered hardware, software, electronic content, and support documentation and services are accessible to people with disabilities. In addition, the revised requirements include functional performance criteria, which are outcome-based provisions that apply in two limited instances: when the technical requirements do not address one or more features of ICT or when evaluation of an alternative design or technology is needed under equivalent facilitation.</blockquote> |
| | |
| | The full (lengthy) information about the ICT Accessibility 508 Standards and 255 Guidelines is found here: [https://www.access-board.gov/ict/ https://www.access-board.gov/ict/] |
| | |
| | The specific software requirements that LabLynx will likely need to consider under Section 508 appear to be found in [https://www.access-board.gov/ict/#chapter-5-software Chapter 5: Software] and [https://www.access-board.gov/ict/#chapter-6-support-documentation-and-services Chapter 6: Support Documentation and Services]. (If for some reason LLX is in the hardware domain, they'll want to also consider[https://www.access-board.gov/ict/#chapter-4-hardware Chapter 4: Hardware] If you're curious about the underlying standards, you can find them in [https://www.access-board.gov/ict/#chapter-7-%C2%A0-referenced-standards Chapter 7: Referenced Standards]. |
| | |
| | Finally, the Section 508 government website has a full Design & Develop section that may be applicable to development process: [https://www.section508.gov/develop/ https://www.section508.gov/develop/] |
| | |
| | ==Additional information== |
| | |
| | 1. The Section 508 website and its glossary mention LIMS under "[https://www.section508.gov/art/glossary/#S scientific instrument]," though only secondarily. At the end: "If a scientific instrument is integrated with a computer or a monitor, the computer (and associated operating system) and the monitor would be separate EIT deliverables, requiring their own Government Product Accessibility Templates (GPAT). If the computer included application software, this software would be another EIT deliverable requiring its own GPAT." |
| | |
| | 2. It appears some software can qualify for "a legally-defined Exception (Back Office)," as found in this example with STARLIMS and the VA: [https://www.oit.va.gov/Services/TRM/ToolPage.aspx?tid=7502 https://www.oit.va.gov/Services/TRM/ToolPage.aspx?tid=7502] |
| | |
| | 3. Some additional posts and guides that may be revealing: |
| | * [https://www.levelaccess.com/how-do-i-determine-if-my-web-site-or-application-is-section-508-compliant/ How do I determine if my website or application is Section 508 compliant?] |
| | * [https://ftp.cdc.gov/pub/Software/RegistryPlus/508%20Compliance/508softwareandos.doc GSA Guide For Making Software Applications and Operating Systems Accessible] (.doc file; NOTE: No date, so not sure if incorporates amended material, so be careful) |
| | * [https://www.dhs.gov/publication/dhs-section-508-compliance-test-processes DHS Section 508 Compliance Test Processes] |
The laws themselves
(b) Manufacturing
A manufacturer of telecommunications equipment or customer premises equipment shall ensure that the equipment is designed, developed, and fabricated to be accessible to and usable by individuals with disabilities, if readily achievable.
(c) Telecommunications services
A provider of telecommunications service shall ensure that the service is accessible to and usable by individuals with disabilities, if readily achievable.
(d) Compatibility
Whenever the requirements of subsections (b) and (c) are not readily achievable, such a manufacturer or provider shall ensure that the equipment or service is compatible with existing peripheral devices or specialized customer premises equipment commonly used by individuals with disabilities to achieve access, if readily achievable.
The term disability is defined here. You can read the full entry, but the basics are:
(1) Disability The term “disability” means, with respect to an individual—
- (A) a physical or mental impairment that substantially limits one or more major life activities of such individual;
- (B) a record of such an impairment; or
- (C) being regarded as having such an impairment (as described in paragraph (3)).
The term readily achievable is defined here. It is defines as:
(9) Readily achievable The term “readily achievable” means easily accomplishable and able to be carried out without much difficulty or expense. In determining whether an action is readily achievable, factors to be considered include—
- (A) the nature and cost of the action needed under this chapter;
- (B) the overall financial resources of the facility or facilities involved in the action; the number of persons employed at such facility; the effect on expenses and resources, or the impact otherwise of such action upon the operation of the facility;
- (C) the overall financial resources of the covered entity; the overall size of the business of a covered entity with respect to the number of its employees; the number, type, and location of its facilities; and
- (D) the type of operation or operations of the covered entity, including the composition, structure, and functions of the workforce of such entity; the geographic separateness, administrative or fiscal relationship of the facility or facilities in question to the covered entity.
2. Rehabilitation Act of 1973, Section 508, amended (29 U.S.C. 794d - Electronic and information technology)
There's a government website dedicated to Section 508: https://www.section508.gov/ The related laws and polices can be found here. The intro states (italics emphasis mine):
In 1998, Congress amended the Rehabilitation Act of 1973 to require Federal agencies to make their electronic and information technology (EIT) accessible to people with disabilities. The law (29 U.S.C § 794 (d)) applies to all Federal agencies when they develop, procure, maintain, or use electronic and information technology. Under Section 508, agencies must give disabled employees and members of the public access to information comparable to the access available to others.
The U.S. Access Board is responsible for developing Information and Communication Technology (ICT) accessibility standards to incorporate into regulations that govern Federal procurement practices. On January 18, 2017, the Access Board issued a final rule that updated accessibility requirements covered by Section 508, and refreshed guidelines for telecommunications equipment subject to Section 255 of the Communications Act. The final rule went into effect on January 18, 2018.
The rule updated and reorganized the Section 508 Standards and Section 255 Guidelines in response to market trends and innovations in technology. The refresh also harmonized these requirements with other guidelines and standards both in the U.S. and abroad, including standards issued by the European Commission, and with the World Wide Web Consortium (W3C) Web Content Accessibility Guidelines (WCAG 2.0), a globally recognized voluntary consensus standard for web content and ICT.
In discussing ICT, the U.S. Access Board summarized the key provisions as such:
The Revised 508 Standards and 255 Guidelines replace the current product-based regulatory approach with an approach based on ICT functions. The revised technical requirements, which are organized along the lines of ICT functionality, provide requirements to ensure that covered hardware, software, electronic content, and support documentation and services are accessible to people with disabilities. In addition, the revised requirements include functional performance criteria, which are outcome-based provisions that apply in two limited instances: when the technical requirements do not address one or more features of ICT or when evaluation of an alternative design or technology is needed under equivalent facilitation.
The full (lengthy) information about the ICT Accessibility 508 Standards and 255 Guidelines is found here: https://www.access-board.gov/ict/
The specific software requirements that LabLynx will likely need to consider under Section 508 appear to be found in Chapter 5: Software and Chapter 6: Support Documentation and Services. (If for some reason LLX is in the hardware domain, they'll want to also considerChapter 4: Hardware If you're curious about the underlying standards, you can find them in Chapter 7: Referenced Standards.
Finally, the Section 508 government website has a full Design & Develop section that may be applicable to development process: https://www.section508.gov/develop/
Additional information
1. The Section 508 website and its glossary mention LIMS under "scientific instrument," though only secondarily. At the end: "If a scientific instrument is integrated with a computer or a monitor, the computer (and associated operating system) and the monitor would be separate EIT deliverables, requiring their own Government Product Accessibility Templates (GPAT). If the computer included application software, this software would be another EIT deliverable requiring its own GPAT."
2. It appears some software can qualify for "a legally-defined Exception (Back Office)," as found in this example with STARLIMS and the VA: https://www.oit.va.gov/Services/TRM/ToolPage.aspx?tid=7502
3. Some additional posts and guides that may be revealing: