13. Secure Software Development and Product Security

Previous Next

2025.1

Niche Studio development team follows the latest security best practices when developing software, and automates security testing throughout development lifecycle whenever possible.

Security is integrated into all phases of Niche Studio product development lifecycle, including:

  • Secure Design:

    • App Risk classification
    • Security req definition
    • Secure application design / RFC
    • Threat modeling
    • App data flow analysis

  • Secure Development and Testing:

    • Secure coding guidelines
    • Peer review

    • Security testing that includes:

      • Linting with security rules
      • Open source security analysis
      • Static secure code analysis
      • Dynamic security analysis
      • Penetration testing

    • Responsible vulnerability disclosure / bug bounty program

  • Remediation:

    • Follows defined vulnerability management lifecycle
    • Ensures no high risk security vulnerability is in production

Details about the Niche Studio software application architecture and security are documented on the product development / engineering wiki.

Policy Statements

Niche Studio policy requires that:

(a) Niche Studio software engineering and product development is required to follow security best practices. Product should be “Secure by Design” and “Secure by Default”.

(b) Quality assurance activities must be performed. This may include

  • peer code reviews prior to merging new code into the main development branch (e.g. master branch); and
  • thorough product testing before releasing to production (e.g. unit testing and integration testing).

(c) Risk assessment activities (i.e. threat modeling) must be performed for a new product or major changes to an existing product.

(d) Security requirements must be defined, tracked, and implemented.

(e) Security analysis must be performed for any open source software and/or third-party components and dependencies included in Niche Studio software products.

(f) Static application security testing (SAST) must be performed throughout development and prior to each release.

(g) Dynamic application security testing (DAST) must be performed prior to each release.

(h) All critical or high severity security findings must be remediated prior to each release.

(i) All critical or high severity vulnerabilities discovered post release must be remediated in the next release or within 30 days, whichever is sooner.

(j) Any exception to the remediation of a finding must be documented and approved by the security team.

Controls and Procedures

Software Development Process

Overview

Software development at Niche Studio follows a release strategy that provides traceability for production software changes. Features, enhancements, and bugs are written up as Issues in Notion. An engineer on a small team proposes changes necessary and creates a review for the team (Bitbucket, Github). Continuous integration (Bitbucket Pipelines, Github Actions) kicks off unit and functional tests which pass before changes are merged into the repository. Once the review is complete, the changes are now deployed to the development environment where regression and end-to-end tests are run before the new code replaces the existing in-service code (test then deploy model). Small teams can decide to follow a source-control branching strategy that makes sense: git-flow, github flow.

Niche Studio practices continuous delivery of code into production through multiple environments: development, testing, production. The deploy process and infrastructure roll-out are written as code (using technologies such as Ansible) and managed under source control.

Niche Studio’s multiple lower environments (dev, test) provide an ecosystem of sample data sets that exercise the application and services when test automation is run. The test environment is where the system is stressed for performance and scalability. Performance and scalability changes are driven by metric data captured through monitoring and logging (metrics before and after change – typically captured as part of the issue description/writeup).

Deployments to production are gated by change control process where an issue is opened which identify what is new/changed (Notion). Sign-offs are recorded by development, testing, security, and product management. Production roll-outs happen on a regular basis without impact to service. This continuous process allows for security updates to roll out regularly and with urgency. If there is impact to production, a rollback is performed to restore service and whatever caused the problem is reverted from source. This restarts the re-proposal approval process of source changes. This process keeps the set of differences between the development environment and the production environment as low as possible.

In the continuous delivery mindset, features are not released by the deployment of code into production, instead features are enabled in production at the appropriate time (dark launching). Feature toggle enablement in production is gated by a change control ticket (Notion) that follows the software roll-out approval process. Feature toggle enablement in production can have a few more dependencies than code. Those dependencies include things like external documentation, early access programs, and internal playbooks for supporting the feature.

Development Environment Architecture

Local Development:

  • Developers work on local machines with secure configurations
  • Code repositories managed through Bitbucket, Github
  • Local development databases isolated and secured
  • Development tools and IDEs configured with security plugins

Staging Environment:

  • Hosted on restricted cloud infrastructure
  • Mirrors production environment configuration
  • Client access provided for testing and approval
  • Automated deployment from development branches

Production Environment:

  • We use Binary Lane (NextDC Brisbane) and DigitalOcean for production hosting.
  • Amazon SES is used for email sending and S3 occasionally for file delivery.
  • We use bastion hosts and Tailscale VPN for administrative access; no direct SSH to production hosts.
  • All changes deployed through automated processes

Secure Development Standards

Traceability of code changes allow for our software to be a living entity. Our current system for documenting changes is Notion. Every commit and/or Pull-Request, should have a Notion supplied that describes contextually why this change is necessary and reasonable. These artifacts over time allow for one to trace the lineage of why our production software and services change over time.

All Niche Studio git repositories have a company standard configuration from a Bitbucket, Github perspective. This standard is a guideline and can be relaxed, but socialize when those exceptions are needed. One example of an exception, is the wiki repository, as editing a wiki and always requiring a PR in this setting slows down ‘flow’.

  • Code: <#>

  • Repo settings: <#>

  • Build: <#>

NOTE: The Sandbox project (and repos) do not follow this standard. And certain projects might be excluded (e.g. wiki).

Developers follow the branch strategy and code review process below:

  1. All development uses feature branches based on the main branch used for the current release. Any changes required for a new feature or defect fix are committed to that feature branch.

    • These changes must be covered under 1) a unit test where possible, or 2) integration tests.
    • Integration tests are required if unit tests cannot reliably exercise all facets of the change.

  2. Developers are strongly encouraged to follow the commit message conventions suggested by GitHub.

    • Commit messages should be wrapped to 72 characters.
    • Commit messages should be written in the present tense. This convention matches up with commit messages generated by commands like git merge and git revert.
    • Additionally, the commit messages should start with the Notion Issue ID when applicable.

  3. Once the feature and corresponding tests are complete, a pull request (PR) will be created using the Bitbucket, Github web interface. The pull request should indicate which feature or defect is being addressed and should provide a high-level description of the changes made.

  4. Code reviews are performed as part of the pull request procedure. Once a change is ready for review, the author(s) will notify other engineers using an appropriate mechanism, typically by adding reviewers as PR approvers.

    • Other engineers will review the changes, using the guidelines above.
    • Engineers should note all potential issues with the code; it is the responsibility of the author(s) to address those issues or explain why they are not applicable.
    • If changes/commits are made to a PR, it should reset previous approvals and require review and approvals again before the PR can be merged.
    • Once the review process finishes, each reviewer should approve the PR, at which point the original author(s) may merge their change into the main branch (i.e. master).
    • PR can only be merged with at least one approval from a reviewer other than the author.

  5. If the feature or defect interacts with sensitive data, or controls access to sensitive data, or contains security/risky infrastructure changes to the target environment, the code changes must be reviewed by the Security team before the feature is marked as complete.

    • This review must include a security analysis for potential vulnerabilities such as those listed in the OWASP Top 10.
    • This review must also verify that any actions performed by authenticated users will generate appropriate audit log entries.

Release Strategy

Features, enhancements, and bugs are written up as issues (Notion). An engineer on a small team proposes changes necessary and creates a review for the team (Bitbucket, Github). Continuous integration (Bitbucket Pipelines, Github Actions) kicks off unit and functional tests which pass before changes are merged into the repository. Once the review is complete, the changes are now deployed to the development environment where regression and end-to-end tests are run before the new code replaces the existing in-service code (test then deploy model). Small teams can decide to follow a source-control branching strategy that makes sense: git-flow, github flow.

Niche Studio practices continuous delivery of code into production through multiple environments: development, testing, production. The deploy process and infrastructure roll-out are written as code (Terraform) and managed under source control.

Niche Studio’s multiple lower environments (dev, test) provide an ecosystem of sample data sets that can be used to exercise the application and services when test automation is run. The test environment is where the system is stressed for performance and scalability. Performance and scalability changes are driven by metric data captured through monitoring and logging (metrics before and after change - typically captured as part of the issue description/writeup).

Deployments to production are gated by change management process where an issue is opened which identify what is new/changed (Notion). Sign-offs are recorded by development, testing, security, and product management. Production roll-outs happen on a regular basis without impact to service. This continuous process allows for security updates to roll out regularly and with urgency. If there is impact to production, a rollback is performed to restore service and whatever caused the problem is reverted from source. This restarts the re-proposal approval process of source changes.

This process keeps set of differences between the development environment and the production environment as low as possible.

Features may be released via code deployments or features may be enabled in production at an appropriate time (dark launching). Feature toggle enablement in production is gated by the same change management ticket (Notion) that follows the software roll-out approval process. Feature toggle enablement in production can have a few more dependencies than code. Those dependencies include things like external documentation, early access programs, and internal playbooks for supporting the feature.

Automated Deployment (Trellis/Composer)

Trellis Framework:

  • Ansible-based server provisioning and configuration
  • Infrastructure as Code (IaC) approach
  • Consistent server configurations across environments
  • Automated security hardening and updates

Composer Integration:

  • WordPress dependency management
  • Automated plugin and theme updates
  • Security vulnerability scanning
  • Dependency conflict resolution

Deployment Process:

  • Staging deployment for testing and client approval
  • Production deployment only after approval
  • Automated rollback capabilities
  • Zero-downtime deployments where possible

Security Controls

Server Security:

  • Ubuntu LTS with CIS Benchmark hardening
  • Automated security updates via unattended-upgrades
  • Fail2ban for intrusion prevention
  • Cloudflare integration for DDoS protection

Network Security:

  • Tailscale VPN for administrative access
  • No external SSH access
  • Firewall rules managed via Ansible
  • SSL/TLS encryption for all connections

Access Management:

  • Multi-factor authentication enforced
  • Role-based access control
  • Regular access reviews and updates
  • Audit logging for all administrative actions

Client Data Protection

Data Handling:

  • Client data isolated per project
  • Encryption at rest and in transit
  • Regular data backup and testing
  • Secure data deletion procedures

Access Controls:

  • Client access only to staging environments
  • No production data access for clients
  • Secure file transfer protocols
  • All access logged and monitored

Privacy Compliance:

  • Australian Privacy Act 1988 compliance
  • Data sovereignty requirements met
  • Client data processing agreements
  • Regular privacy impact assessments

Detailed process and procedures for code promotion and production release: See Configuration and Change Management.

Source Code Management

Niche Studio development/engineering team uses Bitbucket, Github for source code management. Access to Bitbucket, Github and its configuration standards include:

  • All developers must authenticate to gain access to Bitbucket, Github and code repos hosted on Bitbucket, Github according to standards and procedures defined in the Access Policy:

  • Access control to the Bitbucket, Github web interface must be enabled, via SSO and/or MFA if applicable

  • SSH public/private key access may be used for command line or git access to the code repos

  • All code repos in Bitbucket, Github follow these configuration standards:

  • All repos must have an owner identified and listed

  • All repos are by default private

  • Certain branch restrictions are enabled, including:

  • The master branch cannot be rebased

  • Restrict direct commits into master

  • Restrict history rewrites of master

  • Restrict deletion of master

  • Certain pull request (PR) requirements are enforced before merging, including:

  • Must have at least 1 review approval to merge

  • Must have at least 1 successful build to merge

  • all PR tasks must be completed

High Level Application Security Requirements

All Niche Studio software must be developed to include the following general application security principles and requirements. Web applications must also protect itself against the OWASP Top 10 vulnerabilities.

  1. Protect sensitive customer data such as PII and account passwords. Encrypt data stored (at rest).

  2. Secure data in transit and customer communications via TLS.

  3. Provision strong access control (authentication and authorisation). Prevent and report unauthorized access.

  4. Log all transactions and activities to be able to tell who did what, when, where, and how. Mask or remove sensitive data in logs.

  5. Implement client security at application endpoints (e.g. browser, mobile app).

  6. Communicate securely across application endpoints and between service consumers/producers.

  7. Use secure defaults to ensure security when in all error conditions.

  8. Check and maintain the security of all third party and open source libraries/components/dependencies.

  9. Validate all data inputs; encode data outputs when appropriate.

  10. Deploy and configure applications securely to production.

  11. Perform regular vulnerability analysis and apply security patches promptly.

  12. Secure privileged access to production environments and ensure ongoing application monitoring.

All software code must complete a set of security scans/testing prior to being deployed to production, including open source dependency scanning, static and dynamic application security testing, as well as periodic security testing.

For payment processing: - Stripe Checkout implementations require SAQ A compliance - Stripe Elements implementations require SAQ A-EP compliance with quarterly ASV scans

Pre-production testing is performed with nonproduction data in nonproduction environments. Health checks are performed regularly or automated in production.

Software vulnerability identified through any of the above processes shall be reported and tracked following Niche Studio Vulnerability Management process as defined in the Vulnerability Management Policy and Procedures.

Secure Design and Application Threat Modeling

Niche Studio Security Team in collaboration with development team performs full Application Threat Modeling and Risk Assessment on per-application basis using a custom approach that relies on industry standards and best practices.

Major application updates are captured via an RFC process. The RFC template includes Security Consideration as a required section. This section is used to document abuse cases including:

  • risks identified,
  • attack vectors, and
  • mitigating controls.

Each RFC is required to capture sufficient details of the feature/component to be developed, including use cases, motivation and outcome, and the following design details as applicable:

  • authentication/authorisation mechanisms,
  • network communications,
  • data encryption,
  • cloud services used,
  • logging/auditing,
  • data flow diagram/description,
  • edge cases, drawbacks, and alternatives.

The RFC must be approved prior to implementation. Security team is included in RFC reviews via the pull request process.

Platform Design and DevOps Security Details

Documentation on the Niche Studio Engineering Wiki may include additional security specifications as well as the security design and implementation details of the Niche Studio Platform and its supporting operations.

Access Control of the Application (Identification, Authentication, Authorization, Accounting)

Niche Studio external software application that is customer facing with access to customer specific data, including sensitive information such as PII , implements strong access control, covering the Identification, Authentication, Authorization, and Accounting/Auditing (IAAA) of access and user activity.

The implementation ensures that

  • the user requesting access is the one claimed (Identification and Authentication);

  • only users authorized to access specific data are allowed to (Authorization); and

  • their access activities are logs (Accounting/Auditing) according to the Niche Studio auditing standards.

The current implementation leverages Google Workspace for user identity management and access.

The backend platform implements granular Attribute-Based Access Control (ABAC) for granting access to specific services and data based on the attribute(s) of a principal (i.e. user requesting access – an attribute could be the role or group membership or organisation the user belongs to) and the attribute(s) of the requested resource (i.e. data or service – an attribute could be the project this data belongs to).

More implementation details are documented on the internal Engineering wiki.

Free and Open Source Software (FOSS) Security

Niche Studio security and development team implemented a process to

  • Inventory all software dependencies;
  • Scan software dependencies for known security vulnerability;
  • Fix any and all high risk findings prior to production; and
  • Review and identify licensing issues of the 3rd party software and libraries.

The current tool in use is Snyk. Snyk supports Node.js, Ruby, and Java. Documentation can be found at the Snyk website.

Snyk also enables automatic license analysis for dependencies, and this functionality is embedded into the securityScan() Bitbucket Pipelines, Github Actions pipeline step.

Snyk can be leveraged in local development environment to scan locally and/or at every build for dev to include dev dependencies.

Static Application Security Testing (SAST)

Tools:

  • The Lint and GitLeaks Platform - static and dynamic code analysis. Together with the FOSS security tool, the SAST testing was made available to use via the automated security-scan docker image, as well as integrated into Niche Studio Bitbucket Pipelines, Github Actions pipeline library via the securityScan() step

  • Manual code security reviews are periodically performed by the Security team as follows:

    • Periodic review as part of weekly activities

    • Every pull request which includes security team as approvers

    • By request - Notion issue created on the Security project/board

Dynamic Application Security Testing (DAST)

Dynamic testing is available by request to the Security team and is performed using OWASP ZAP. Security team is currently looking into automation of this type of scanning.

Additionally, manual baseline dynamic testing is available by request to the Security team.

Integration of Dynamic testing into automatic tests

Upon availability of automatic UI tests for applications being developed internally, an extension based on OWASP ZAP is used to transparently work with any UI tests available and automatically add basic dynamic tests into build pipeline.

Security Testing

External Security Testing

External security testing is performed at least once a year by a qualified security researcher / ethical hacker on the security team internally and/or with an external security consulting firm.

For payment processing sites using Stripe Elements (SAQ A-EP), quarterly ASV scans are required in addition to annual penetration testing.

Third party security testing of client sites is also available to clients using their own provider.

Coordinated Vulnerability Disclosure

Niche Studio maintains a Coordinated Vulnerability Disclosure (CVD/VDP) program with security.txt at /.well-known/security.txt and a dedicated security email inbox (security@team.nichestud.io) for responsible disclosure.

Coordinated Vulnerability Disclosure (CVD) / Vulnerability Disclosure Policy (VDP)

All technology contains bugs, including both functional defects and security vulnerability.

We maintain a Coordinated Vulnerability Disclosure (CVD) / Vulnerability Disclosure Policy (VDP).

  • Researchers can report via /.well-known/security.txt and security@team.nichestud.io
  • Contact: security@team.nichestud.io
  • Policy: https://policies.nichestud.io/vulnerability-disclosure
  • Acknowledgments: We acknowledge responsible researchers who help improve our security
  • Public bug bounties may be considered later; today we triage via our CVD inbox

Outsourced Software Development

Niche Studio requires all outsourced software development to follow the same rigor and process as internal engineering. Outsourced developers must develop in our secure environment, accept and follow our security policies and procedures, and comply with the same secure coding standards, including:

  • Receive regular OWASP or equivalent secure coding training.

  • Follow the same source control, code review, and security code scanning procedures as defined.

  • Install endpoint compliance agent that checks to make sure firewall, encryption, patching, password policy, screensaver password, and other required protection is properly configured.

Additionally, the third party firm providing outsourced development services must demonstrate that they have conducted the appropriate screening during hiring.

PCI DSS Compliance with Stripe

Niche Studio uses Stripe for payment processing to minimise PCI DSS compliance scope and reduce security risks. This procedure outlines the requirements for maintaining PCI DSS compliance when using Stripe.

Stripe Checkout = SAQ A

When using Stripe Checkout (hosted payment pages), Niche Studio qualifies for SAQ A compliance: - All payment processing occurs on Stripe’s hosted pages - No cardholder data touches Niche Studio systems - Minimal security requirements apply - Annual self-assessment questionnaire completion required

Stripe Elements = SAQ A-EP

When using Stripe Elements (embedded payment forms), Niche Studio qualifies for SAQ A-EP compliance:

SAQ A-EP Eligibility

Niche Studio qualifies for SAQ A-EP when:

  • All payment card data is handled by Stripe (no card data touches Niche Studio systems)
  • Payment forms use Stripe Elements (embedded JavaScript)
  • JavaScript and CSS from Niche Studio domain may be loaded on payment pages
  • No cardholder data is stored, processed, or transmitted by Niche Studio
  • Required security controls for e-commerce script integrity are implemented

Stripe Elements Implementation Requirements

Payment Form Implementation: 1. Use Stripe Elements: Implement Stripe Elements for embedded payment forms 2. Script Integrity Controls: Implement required security controls for e-commerce script integrity 3. No Custom Forms: Do not create custom payment forms that handle card data 4. Secure Loading: Only load Stripe.js and Elements from Stripe domains

SAQ A-EP E-commerce Script Integrity Requirements (PCI DSS v4.0.1 6.4.3, 11.6.1): 1. Subresource Integrity (SRI): Implement SRI hashes for all Stripe scripts 2. Content Security Policy (CSP): Configure CSP to restrict script sources to Stripe domains only 3. Quarterly Script Reviews: Review and validate all payment page scripts quarterly 4. Tamper Detection: Implement logging and alerting for script integrity violations 5. Script Whitelisting: Maintain approved list of scripts allowed on payment pages

Technical Requirements: 1. HTTPS Only: All payment pages must use HTTPS 2. No Card Data Storage: Never store cardholder data on Niche Studio systems 3. Secure Communication: All communication with Stripe must use TLS 1.2 or higher 4. No Sensitive Data Logging: Do not log any cardholder data or sensitive authentication data

Network Security

Firewall Configuration: 1. Default Deny: Implement default deny firewall rules 2. Minimal Access: Restrict access to only necessary services 3. Regular Updates: Keep firewall rules updated and reviewed quarterly 4. Documentation: Maintain current network diagrams and firewall rules

Wireless Networks: 1. Segregation: Keep wireless networks separate from payment processing systems 2. Encryption: Use WPA2 or WPA3 encryption for all wireless networks 3. Default Changes: Change all default wireless settings 4. Monitoring: Monitor wireless network access and usage

Access Control

User Access: 1. Unique IDs: Assign unique user IDs to all personnel 2. Strong Authentication: Use strong passwords or multi-factor authentication 3. Access Reviews: Conduct quarterly access reviews 4. Immediate Revocation: Revoke access immediately upon termination

Physical Access: 1. Restricted Areas: Limit physical access to payment processing systems 2. Visitor Logs: Maintain visitor logs for all restricted areas 3. Badge System: Use photo ID badges for all personnel 4. Regular Reviews: Review physical access quarterly

Vulnerability Management

Regular Scans: 1. Quarterly Scans: Conduct quarterly vulnerability scans 2. ASV Scans: Use Approved Scanning Vendor (ASV) for external scans 3. Remediation: Address all high-risk vulnerabilities within 30 days 4. Documentation: Document all scan results and remediation actions

Patch Management: 1. Regular Updates: Apply security patches within 30 days 2. Critical Patches: Apply critical patches within 7 days 3. Testing: Test patches in non-production environment first 4. Documentation: Document all patch management activities

Monitoring and Logging

Audit Trails: 1. Comprehensive Logging: Log all access to payment systems 2. Log Retention: Retain logs for at least one year 3. Log Protection: Protect logs from unauthorized access 4. Regular Review: Review logs at least daily

Security Monitoring: 1. Intrusion Detection: Implement intrusion detection systems 2. File Integrity: Monitor critical files for unauthorized changes 3. Network Monitoring: Monitor network traffic for anomalies 4. Incident Response: Have procedures for responding to security incidents

Service Provider Management

Stripe Relationship: 1. BAA/DPA: Execute appropriate agreements with Stripe 2. Compliance Verification: Verify Stripe’s PCI DSS compliance annually 3. Service Reviews: Review Stripe services quarterly 4. Incident Notification: Ensure Stripe notifies Niche Studio of security incidents

Other Service Providers: 1. Due Diligence: Conduct due diligence on all service providers 2. Agreements: Execute appropriate agreements with all service providers 3. Compliance Verification: Verify service provider compliance annually 4. Regular Reviews: Review service provider relationships quarterly

Training and Awareness

Staff Training: 1. Initial Training: Provide PCI DSS training to all relevant staff 2. Annual Refresher: Conduct annual PCI DSS training refresher 3. Role-Specific Training: Provide role-specific training as needed 4. Documentation: Document all training activities

Awareness Program: 1. Regular Updates: Provide regular security awareness updates 2. Incident Reporting: Train staff on incident reporting procedures 3. Best Practices: Share security best practices regularly 4. Feedback: Collect feedback on training effectiveness

Compliance Validation

SAQ A Completion: 1. Annual Assessment: Complete SAQ A assessment annually 2. Quarterly Reviews: Conduct quarterly compliance reviews 3. Documentation: Maintain all compliance documentation 4. Remediation: Address any compliance gaps immediately

External Validation: 1. ASV Scans: Use ASV for external vulnerability scans 2. Penetration Testing: Conduct annual penetration testing 3. Compliance Audits: Consider external compliance audits 4. Certification: Maintain appropriate security certifications

Incident Response

Breach Response: 1. Immediate Response: Respond to security incidents immediately 2. Containment: Contain security incidents as quickly as possible 3. Notification: Notify appropriate parties within required timeframes 4. Documentation: Document all incident response activities

Recovery: 1. Business Continuity: Maintain business continuity during incidents 2. System Restoration: Restore systems to secure state 3. Lessons Learned: Conduct post-incident reviews 4. Process Improvement: Update procedures based on lessons learned

HIPAA Best Practices for Software Development

Use only HIPAA eligible services in the Cloud (AWS)

Because we use the services provided by AWS for our production environment with contains electronic protected health information (ePHI), AWS is a “business associate” of ours. It is required by HIPAA for Niche Studio and AWS to enter into a “business associate agreement” (BAA).

Our fully executed BAA with AWS can be found on the internal document repository.

We must only used HIPAA-eligible services covered under the BAA to process and store ePHI. Non-eligible services may be used in support of our cloud infrastructure as long as it does not have access to ePHI.

A list of HIPAA eligible services can be found here. AWS regularly updates its services to meet HIPAA compliance requirements. Check the page once in a while to find out if new services have been added.

Additional References:

Separate access and data between prod and non-prod accounts

It is a compliance requirement of multiple regulations to ensure separation of duties between production and non-production environments, including both access and data. Additionally, we should not use production data for dev or test, unless the data has been properly sanitized/masked.

Examples of regulations and certifications that have this explicit requirement include HIPAA, SAS70/SSAE-17, SOC, PCI, and ISO 27001/27002, many of which are on our target list to be compliant with or certified to.

Do not log ePHI

Not only it is a security best practice to avoid sensitive data such as ePHI in application logging, it may be a contract violation (per AWS BAA) to do so. We must not send any ePHI to non HIPAA eligible services in AWS, such as CloudTrail.

Include the right language in notices

Specific language must be included in terms, consents, and notices. For example, we must collect email addresses from patients when they sign up for the PHC, and specify in the terms that we may use the email address provided as a formal method of communication, including breach notification, should a breach occurs that impact their PHI.

Data protection

Follow the requirements listed in the following documents:

Risk Analysis and Compliance Assessment

For more details on Niche Studio’s HIPAA compliance, refer to the HIPAA Business Associate Agreement and HIPAA Controls Mapping documents in the References section.

Production System Monitoring and Paging

Software and systems deployed in production are monitored 24/7 for health check and other major/critical error conditions. The on call team is paged via PagerDuty in the event an error or failure is detected.

Notifications via additional channels such as Slack and email are also configured.

12. Data Protection 14. Configuration and Change Management