Where will your Patient Data be stored?
HIMSA production systems for Noah ES are located in Microsoft Azure datacenter facilities in:
United States
Europe
Noah ES Accounts are established in one of these regions based on where the Customer business is located.
| Tip |
|---|
Patient Data associate with your Noah ES Account is only stored, processed within the applicable region. For example, if your business is located in Europe your Patient Data will be processed and stored within the EU |
Who are HIMSA's sub-processors?
We maintain an up-to-date list of the names and locations of all sub-processors used for hosting or other processing of Service Data.
Noah ES uses certain platform subprocessors, as well as infrastructure suppliers and other third-party business partners, to provide services to its customers.
Company | Purpose | Location |
|---|---|---|
HIMSA Makes use of the below Azure Data Center products
|
| United States | |
Sendgrid is an email service provider used within Noah ES to send notification emails to Noah ES user accounts. The primary information Sendgrid has access to is the email addresses of recipients of the emails and the content of the emails themselves. The content of the emails contains topics such as instructions and links to set passwords via the Noah ES portal, account activity, business related topics such as monthy or annual charges. Patient data is never process through this service. | United States | |
Stripe provides secure payment processing services. Stripe will have access to personal and credit card information that your company will use to pay for Noah ES services. HIMSA never keeps a copy of your credit card information. | United States | |
HIMSA makes use of Atlassian’s Jira Service desk application to provide technical support via the Noah ES support portal. | Australia | |
HIMSA makes use of the Mongo DB Atlas product. The document style database is a hosted service that HIMSA uses to store Customer Data. The service that HIMSA utilizes is |
implemented within MS Azure data centers matching the customers location, EU = EU data center, U.S. = U.S. datacenter, AU = Australia data center. The service is not used to process or contain any Patient Data. | United States, Ireland |
How does HIMSA respond to legal requests for Service Data?
In certain situations, we may be required to disclose personal data in response to lawful requests by public authorities, including to meet national security or law enforcement requirements. We may disclose personal data to respond to subpoenas, court orders, or legal process, or to establish or exercise our legal rights or defend against legal claims. We may also share such information with relevant law enforcement agencies or public authorities if we believe same to be necessary in order to investigate, prevent, or take action regarding illegal activities, suspected fraud, situations involving potential threats to the physical safety of any person, violations of our Master Subscription Agreement, or as otherwise required by law.
What is a Data Processing Agreement ("DPA")?
HIMSA offers customers a robust Data Processing Agreement ("DPA"), governing the relationship between the customer (acting as a data controller) and HIMSA (acting as a data processor). The DPA facilitates HIMSA's customers' compliance with their obligations under EU data protection law.
Our DPA contains data transfer frameworks to ensure that our customers can lawfully transfer personal data to HIMSA outside of the European Union by relying on one of the following mechanisms: our Binding Corporate Rules, or Standard Contractual Clauses.
Security
Protecting your information and the information of your customers is extremely important to us.
We combine enterprise-class security features with comprehensive audits of our applications, systems, and networks to ensure customer and business data is always protected.
We know you have questions about how we're protecting that information, so what follows are details about some frequently requested information.
Data Centers & network security
We ensure the confidentiality and integrity of your data with industry best practices.
We use Microsoft Azure data centers around the world to host our systems. They all have SOC2 Type 2 reports and provide all the physical security protection measures you would expect.
Application Security
Application security starts as part of the application design through to development and testing. We take steps to securely develop and test against security threats to ensure the safety of our customer data.
We continuously scan our applications for vulnerabilities, using a combination of static source code analysis and dynamic testing. We also:
Encrypt all your data in transit using TLS 1.23
Have an independent audit conducted on an annual basis
Operational Security
Access to our systems and your data is restricted only to those who need access in order to provide you awesome support.
Security is the responsibility of everyone who works for us. We train our employees so that they can identify security risks and empower them to take action to prevent bad things from happening.
Datacenter & network security
Facilities | Physical security, power, and internet connectivity for our service or Azure services are monitored by the facilities providers (Microsoft). |
Monitoring | All Production Network systems, networked services, and application services are constantly monitored. |
Location | HIMSA production systems for Noah ES are located in Microsoft Azure datacenter facilities in:
Noah ES Accounts are established in one of these regions based on where the Customer business is located. |
Protection | Our network is protected by secure HTTPS transport over public networks, regular audits, and network Intrusion Detection and/or Prevention technologies (IDS/IPS) which monitor and/or block malicious traffic and network attacks. |
Architecture | Our network security architecture consists of multiple security zones. More sensitive systems, like database servers, are protected in our most trusted zones. Other systems are housed in zones commensurate with their sensitivity, depending on function, information classification, and risk. |
Network Vulnerability Scanning | Network security scanning gives us deep insight for quick identification of out-of-compliance or potentially vulnerable systems. |
DDoS Mitigation | Our platform contains multiple layers of defense to mitigate Distributed Denial of Service (DDoS) attacks. |
Logical Access | Access to our Production Network and services are restricted, utilizes least privilege, and is controlled by our Operations Team. |
Security Incident Response | In case of a security or system alert, events are escalated to our Operations team. Employees are trained on security incident response processes, including communication channels and escalation paths. |
Encryption in Transit | Communications between you and our servers are encrypted via industry best-practices HTTPS and Transport Layer Security (TLS) over public networks. |
Encryption at Rest | Data, including sensitive patient data is always encrypted at rest via MS SQL TDE |
Uptime | We maintain a publicly available system-status webpage which includes system availability details, scheduled maintenance, service incident history, and relevant security events. |
Redundancy | Our services employs clustering and network redundancies to eliminate single points of failure for high availability. Our strict backup procedures ensures Service Data is actively replicated across primary and secondary systems and facilities. |
Disaster Recovery | Our Disaster Recovery (DR) program ensures that our services remain available or are easily recoverable in the case of a disaster. This is accomplished through building a robust technical environment, creating Disaster Recovery plans, and testing. |
Application security
Security Training | At least annually, engineers participate in secure code training covering OWASP Top 10 security flaws, common attack vectors, and our security controls. |
QA | Our QA department reviews and tests our code base. Several dedicated application security engineers on staff identify, test, and triage security vulnerabilities in code. |
Separate Environments | Testing and staging environments are separated physically and logically from the Production environment. No actual Service Data from production is used in the development or test environments. |
Dynamic Vulnerability Scanning | We employ a number of third-party, qualified security tools to continuously dynamically scan our services and web apps against the OWASP Top 10 security flaws. |
Static Code Analysis | The source code for both our platform, services and applications, are continuously scanned for security issues via our integrated static analysis tooling. |