# Problem * It's a lot of extra work, if it is even possible at this point, to ensure and prove that a project is HIPAA compliant (or any other type of formal compliance such as GDPR). If we can help steer users in the right direction, it may be a nice feature to have. # Important Considerations * If we are maintaining the compliance standards within GitLab that we then use to generate the compliance checks, we will need to identify programmatic access to the standards. * We will need to handle versioning of each type of compliance so we can effectively help users of the checks migrate from one version to another when there are formal policy changes introduced by the external governing body. # Proposal Ideal: * Expose a button in the GitLab UI to generate all the necessary issues to help your project be HIPAA compliant. This could be expanded into GDPR, etc. Minimum: * Improve the Issue CSV Importer to support # Goals Ideal: * Create a framework for keeping compliance standards (HIPAA, GDPR, etc.) up to date and exposing the ability for customers to run compliance checks against a given project. Minimum: * Make the Issue CSV Importer easier to use for real world use cases by improving the primitives already in place such that the general enhancements sufficiently solve for the majority of targeted use cases. [](https://jtbd.info/5-tips-for-writing-a-job-story-7c9092911fc9) # Planning ## Initial Data To Collect * - [ ] Quantitative: Telemetry data for current importer * - [ ] Quantitative: Telemetry data for bulk issue creation via API calls * - [ ] Qualitative: 3-5 problem validation interviews w/ customers * - [ ] Qualitative: 3-5 problem validation interviews w/ prospective customer * - [ ] Qualitative: 5 solution validation interviews w/ current or prospective customers ## ToDo * - [ ] Create issue that will flow through Plan's workflow: ~"validation::backlog" ~"validation::problem" ~"validation::solution" ~"planning breakdown" ~"to schedule" ~"workflow::ready for development" ~"workflow::In dev" ~"workflow::In review" ~"workflow::verification" ~Release ## Related Boards [Plan:Validate](https://gitlab.com/groups/gitlab-org/-/boards/1226305?&label_name[]=devops%3A%3Aplan) | [Plan:Build](https://gitlab.com/groups/gitlab-org/-/boards/1224651?&label_name[]=Plan) # Estimated Value | Area | Score | | ------ | ------ | | Reach | unknown | | Impact | unknown | | Confidence | unknown | | Effort | unknown | # Use Cases * [HIPAA Audit Protocol Workflow](https://about.gitlab.com/2019/07/25/moving-workflows-to-gitlab-the-case-of-the-hipaa-audit-protocol/) # Related Open Issues * https://gitlab.com/gitlab-org/gitlab-ce/issues/58175 * https://gitlab.com/gitlab-org/gitlab-ce/issues/58174 * https://gitlab.com/gitlab-org/gitlab-ce/issues/58172 * https://gitlab.com/gitlab-org/gitlab-ce/issues/63765 # Internal Engineering Input Luka: > say I transform my data set to a CSV in the format of `title,description` — if I have a long, formatted description, I have to take into account (1) a separator might be used, (2) the extra consideration of double quote within a quote, etc > the first part - getting, say, the audit protocol into an importable form, will take me over a week of FTE; the second part, getting it to work with the `title,description` format, will take longer (edited) with the approach in the blog post, it doesn’t matter how the data is structured or its formatting, and I can cleanly insert newlines, add misc. data to the data set, etc