Regulatory Compliance within the Software Industry: Interpretation of Regulatory Ambiguity as a Compliance Concern
Loading...
Links to Files
Permanent Link
Author/Creator
Author/Creator ORCID
Date
2024/01/01
Type of Work
Department
Information Systems
Program
Information Systems
Citation of Original Publication
Rights
This item may be protected under Title 17 of the U.S. Copyright Law. It is made available by UMBC for non-commercial research and education. For permission to publish or reproduce, please see http://aok.lib.umbc.edu/specoll/repro.php or contact Special Collections at speccoll(at)umbc.edu
Distribution Rights granted to UMBC by the author.
Access limited to the UMBC community. Item may possibly be obtained via Interlibrary Loan thorugh a local library, pending author/copyright holder's permission.
Distribution Rights granted to UMBC by the author.
Access limited to the UMBC community. Item may possibly be obtained via Interlibrary Loan thorugh a local library, pending author/copyright holder's permission.
Abstract
Software companies must demonstrate and communicate due diligence toward compliance with applicable regulations and laws within their organizational processes and procedures. The ambiguous phrasing within regulations (i.e., regulatory ambiguities), though, can be challenging for a software developer trying to develop and interpret regulatory compliance requirements for software. Because of this challenge, software organizations or development teams need help communicating and documenting their compliance process during software development. Legal consultants, regulating officials, or compliance auditors can have similar challenges trying to interpret the development work of a software organization and determine if they have applied the requisite amount of due diligence toward regulatory compliance. My dissertation studies a process to assist software developers in interpreting regulatory ambiguities and accomplishes three goals. The first goal is to understand the software industries’ perceptions of compliance through an interview study and survey. The second goal is to observe the reasoning and communication behind interpreting and modeling regulatory ambiguities within a group of software practitioners via a multi-case study. Finally, goal three validates the ambiguity modeling process as useful from an auditor’s perspective through a focus group. The ambiguity modeling process within this work elicits and documents regulatory analysis to support technical compliance decisions and due diligence within a software development process that is reviewable by regulators or external third parties interested in a software organization’s compliance procedures. This approach has advantages for various stakeholders. This process allows software developers to communicate specific instances of ‘gray areas’ in regulation, such as conflicting requirements or unclear terminology, during compliance requirements development so they may receive further guidance and resolution. For auditors assessing organizations for regulatory compliance, ambiguity models demonstrate that software organizations are aware of and discuss their compliance requirements. The models can facilitate meaningful conversations for other stakeholder groups, bridging communication gaps with a software engineering team that can hinder regulatory compliance analysis and development. For the software engineering community, prior research lists challenges with regulatory compliance. My research addresses some of those challenges while promoting compliance communication amongst software stakeholders and assisting in developing a compliance culture within software organizations.