Mocingbird is a cloud-based platform that simplifies ongoing licensing and continuing education requirements for clinicians. The product is offered as a Software-as-a-Service (SaaS) solution. Mocingbird is available on the web and via the Apple App Store or Google Play Store. The product provides license renewal requirements, allows users to upload, view and download their documentation, and enables consumption of third party educational course content to help meet the state and board requirements.
Our primary security focus is to safeguard our users’ data. Our Security and Risk Governance (SARG) Committee has the responsibility to set compliance, privacy and audit policies along with requirements around data security and access for our customers. This team meets, at a minimum monthly, to ensure continued improvement and enhancement of Mocingbird’s security standards. The SARG meets to evaluate logs and/or notifications received for external sources to assess the impact of any incident, breach or outage to develop the mitigation plan. We have designed our security program leveraging industry standards. Our Chief Product Officer and Chief Administrative Officer oversee the implementation of security safeguards across our product and resources, including compliance with legal and regulatory standards.
Our Information Risk Management enables risk mitigation through policies, procedures, and technology that reduces threats from vulnerabilities, poor data security, and from third-party vendors. The risk management practices maintain the superior product and service to customers while protecting the privacy and confidentiality of their informa
We implemented an array of security controls to protect data and processes entrusted to us. Our security controls are designed to allow for a high level of employee efficiency while minimizing risk. We outsource hosting of our product infrastructure to leading cloud infrastructure providers, principally, Amazon Web Services (AWS). AWS provides high levels of physical and network security. Mocingbird's AWS cloud server instance resides in the US. AWS maintains an audited security program. We do not host any product systems within our corporate offices.
Our separate Access Control Policy defines the access to all systems and data. Roles and access are regularly monitored to ensure users have proper permissions across all applications. When moving roles within Mocingbird, access rights are reviewed and, if necessary, changed to reflect the requirements of the individual’s new role. When an individual leaves the Mocingbird organization or a contracted third party, their access rights are removed from all systems and they are obliged to return any Mocingbird owned information and equipment as outlined in the Employee or Contractor Handbooks. All accounts are disabled on the date of termination or suspension.
We enforce an industry standard corporate password policy, which includes 2 factor or multifactor (2FA/MFA) where feasible. We also require a minimum password length of 8 characters and complexity requirements including special characters, upper and lower case characters, and numbers. We prohibit account and password sharing.
Mocingbird users access their data via individual user controls including email, username, and password. Mocingbird does not store, process, or collect customer payment information. We rely on a PCI compliant third party payment vendor to process customer payments on our behalf.
Our separate Data Management policy provides details on classifying, sharing, and retaining data. The data on the Mocingbird platform is clinician data related to their medical licensure. Mocingbird does not collect or store Protected Health Information (PHI) as defined by HIPAA. The Personally Identifiable Information (PII) that a clinician may provide to Mocingbird are name, date of birth (limited instances), possibly the home address, and personal email, though we encourage the use of business address and business emails. Network-level access control lists are implemented in AWS Virtual Private Cloud (VPC) security groups which apply port- and address-level protections to the server instance in the infrastructure. These firewalling technologies deny unintended traffic by default, and all network traffic is logged and used to inform our monitoring mechanisms.
Our platform uses a single page application with APIs to access our data. To limit malware’s ability to intercept and access our data channels, we ensure that all our interactions with the data layer are secure, authenticated and authorized.
We are a SaaS platform, as such, we do not logically separate data by customer per environment. However, we logically separate customer data via access controls to ensure each customer’s data is not co-mingled. Our database uses the provided native encryption capabilities (KMS keys) for encryption of data at rest. As used, AWS S3 has data at rest encryption. Our end to end pipeline is secured with TLS 1.2 or above.
Our database has daily backup with the ability to rollback anytime. Data backups are continuously done by Heroku. We rely on AWS to ensure redundancy. Logical backups that are created with Heroku are stored in an AES-256 encrypted S3 bucket.
Data destruction happens in two instances. The first is immediate on our platform, in the event confidential patient documentation is uploaded to the platform. The second and in general, is the destruction of our backup data after 1 year.
We leverage Amazon S3 endpoint protection for application controls. For all our non platform related data, we use Google suite and have the highest Google recommended security protocols in place. At the application layer, vulnerability and patch management is automated with Github monitoring, and automated hardening & self-healing via Heroku. We have continuous backup and roll-back system setup for all databases. Files stored with AWS S3 have versioning to protect data. Data loss prevention is managed through AWS data loss strategy.
We implement a rapidly-advancing feature set, and we constantly improve our product through a continuous delivery approach to software development. New code is proposed, approved, merged and deployed every 2 weeks. High priority bug fixes may be deployed between the 2 week releases as needed. Major feature changes are communicated via product update posts. Newly developed, built code is first deployed to the dedicated and separate staging environment for the last stage of testing before being promoted to production. Customer data is never in the staging environment, nor does any other testing use customer data.