Software practitioners must implement a growing list of regulatory and security mandates, but have no established tool or mechanism for demonstrating their due diligence or compliance efforts exists. Providing an approach does more than help software practitioners. External agencies and auditors also need tools or mechanisms to enforce compliance requirements. Consumers also benefit. Standardized approaches a mechanism for accountability regarding compliance without software organizations compromising its proprietary or sensitive information. Currently, perceptions, practices, or decision making on regulatory or security standard compliance is not a well researched area in academia. Our research aims to understand the practices and decision making software organizations apply toward regulatory compliance requirements during the software development process. Then, we take this improved understanding and apply it to building an approach that auditors or regulators can use to validate regulatory compliance throughout the entire software development process.

Compliance reviews within a software organization are internal attempts to verify regulatory and security requirements during product development before its release. However, these reviews are not enough to adequately assess and address regulatory and security requirements throughout a software's development lifecycle. We believe requirements engineers can benefit from an improved understanding of how software practitioners treat and perceive compliance requirements. This paper describes an interview study seeking to understand how regulatory and security standard requirements are addressed, how burdensome they may be for businesses, and how our participants perceived them in the software development lifecycle. We interviewed 15 software practitioners from 13 organizations with different roles in the software development process and working in various industry domains, including big tech, healthcare, data analysis, finance, and small businesses. Our findings suggest that, for our participants, the software release process is the ultimate focus for regulatory and security compliance reviews. Also, most participants suggested that having a defined process for addressing compliance requirements was freeing rather than burdensome. Finally, participants generally saw compliance requirements as an investment for both employees and customers. These findings may be unintuitive, and we discuss seven lessons this work may hold for requirements engineering.