Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
This security domain is designed to ensure that any data consumed from Microsoft 365 is adequately protected both in transit and at rest. This domain also ensures that consumers’ (data subjects) privacy concerns are being met by the ISV, in line with GDPR (General Data Protection Regulation) and HIPAA (Health Insurance Portability and Accountability Act of 1996).
Data in Transit
The connectivity requirements of Microsoft 365 developed apps/add-ins necessitate communication over public networks, specifically the internet. Therefore, data in transit must be suitably protected. This section covers the protection of data communications over the Internet.
Control No. 1
Please provide evidence for all of the following:
Validate that your TLS Configuration is TLS1.2 or higher.
An inventory of trusted keys and certificates is kept and maintained.
Intent: TLS
The intention of this subpoint is to ensure that Microsoft 365 data being consumed by your organization is transmitted securely. The TLS Profile Configuration is used to define TLS specific requirements that help ensure traffic is secure against man-in-the-middle attacks.
Guidelines: TLS
The easiest way to evidence this is to run the Qualys SSL Server Test tool against ALL web listeners, including any that run on nonstandard ports.
Please remember to tick the “Do not show the results on the boards” option, which stops the URL from being added to the website.
The TLS Profile Configuration Requirements can be demonstrated by providing evidence of individual checks. To provide evidence of specific settings, such as disabling TLS Compression, configuration settings, scripts, and software tools can be utilized.
Example evidence: TLS
The following screenshot shows the results of SSL scan by Qualys for the webappfrontdoor- byendbagh6a0fcav.z01.azurefd.net.
The Protocols section shows that TLS1.2 is the only protocol supported/ enabled.
Note: The certification analysts will review the full output of the scan to confirm all requirements of the TLS profile configuration requirements are met. The expectation will be that scans are provided for all end points that are publicly exposed (IP Addresses and URLs) to the backend environment that is in scope. Depending on what evidence has been provided, the analysts may run their own Qualys scan.
Example evidence: TLS
The following screenshot shows the configuration settings for TLS in Azure app service followed by TLS enumeration via PowerShell.
Intent: keys and certificates
The intention of this subpoint is to ensure that a comprehensive inventory of trusted keys and certificates is maintained, which involves identifying various systems, services, and applications that depend on these cryptographic elements.
Guidelines: keys and certificates
The evidence must demonstrate that an inventory of trusted keys and certificates exists and is maintained. Additionally, applicable evidence of the tools used to store the actual keys and certificates can be provided such as Azure key vault, HashiCorp Vault Secrets, Confluence Cloud, etc.
Example evidence: keys and certificates
The following screenshot shows that a key and a certificate inventory is maintained in Confluence Cloud.
The following screenshot shows the approved list of trusted keys and certificates. It includes details such as the certificate, keys, cyphers, and the systems on which they are installed.
The following screenshot is from HashiCorp Vault. The certificates that are outlined and recorded in the inventory list are being stored in this online vault. HashiCorp Vault is an open-source tool for secrets management, encryption as a service, and privileged access management.
The following screenshot is an extract of the actual certificate and the keys stored inside the online vault.
Note: The expectation will be that the storage location of the keys has appropriate access controls in place. If the private key is compromised, someone could spoof the server with a legitimate certificate.
Example evidence: keys and certificates
An inventory of trusted keys and certificates can also be maintained with Microsoft 365 Defender which provides an Inventory feature as shown in the next screenshot.
The next screenshot shows the details of the certificate.
Please note: These examples are not full screen screenshots, you will be required to submit full screen screenshots with any URL, logged in user and the time and date stamp for evidence review. If you are a Linux user this can be done via the command prompt.
Control No. 2
Please provide evidence for all of the following which:
Shows TLS compression is disabled for all public facing services handling web requests to prevent CRIME (Compression Ratio Info-leak Made Easy).
Validates that TLS HSTS is enabled and configured to 180-days across all sites.
Intent: TLS
The CRIME (Compression Ratio Info-leak Made Easy (CVE-2012-4929)) attack is a vulnerability in the compression of the Secure Sockets Layer (SSL)/Transport Layer Security (TLS) protocols. For this reason, industry recommendations are to disable SSL compression.
HTTP Strict Transport Security (HSTS) is a security mechanism designed to protect websites against man-in-the-middle attacks by forcing TLS connections by way of a HTTPS response header field named "Strict-Transport-Security".
Guidelines: TLS
This can be evidenced through the Qualys SSL Labs tool. Example evidence: TLS
The following screenshot shows that SSL/TLS compression is disabled.
The next screenshot shows that HSTS is enabled.
Note: The certification analyst will review the full output to confirm all requirements of the TLS Profile Configuration Requirements are met (Please provide screenshots of the full scan output). Depending on what evidence has been provided, the analysts may run their own Qualys scan.
Other tools that can be used to check that HSTS is enabled are 'HTTP Header Spy', and
securityheaders.com as shown in the examples following. Additional Evidence
Screenshots such as configuration settings of the security headers, specifically HSTS can be provided to further demonstrate the security posture of the public footprint.
The next screenshots show the Azure Front Door configuration and the rule set implemented for rewriting the headers.
The next screenshot shows the security headers scan performed and that all security headers are implemented, not just HSTS.
Note: If Qualys SSL Scanner or Security Headers are used, the expectation will be that the full report is provided for a review.
Data at rest
When data consumed from the Microsoft 365 platform is stored by ISVs, data needs to be suitably protected. This section covers protection requirements of data stored within databases and file stores.
Control No. 3
Provide demonstratable evidence that data at rest is encrypted in line with the encryption profile requirements, using encryption algorithms such as AES, Blowfish, TDES and encryption key sizes of 128-bit, and 256-bit.
Intent:
Some older encryption algorithms are known to contain some cryptographic weaknesses which increases the chances of a threat actor being able to decrypt the data without knowledge of the key. For this reason, the intent of this control is to ensure only industry accepted encryption algorithms are used to protect stored M365 data.
Guidelines:
Evidence can be provided by way of screenshots, showing the encryption being employed to protect M365 data within databases and other storage locations. The evidence should demonstrate the encryption configuration is in line with the Encryption Profile Configuration Requirements of the Microsoft 365 Certification.
Example evidence:
The next screenshot shows that TDE (Transparent Data Encryption) is enabled on the Contoso database. The second screenshot shows the Microsoft documentation page Transparent data encryption for SQL Database, SQL Managed Instance, and Azure Synapse Analytics showing that AES 256 encryption is used for Azure TDE.
Please Note: In the previous examples full screenshots were not used, however ALL ISV submitted evidence screenshots must be full screenshots showing URL, any logged in user and system time and date.
Example evidence:
The following screenshot shows Azure Storage configured with encryption for blobs and files. The next screenshot shows the Microsoft Documentation page Azure Storage encryption for data at rest showing that Azure Storage uses AES-256 for encryption.
Data retention, back-up, and disposal
Where ISVs consume and store Microsoft 365 data, there is the risk of a data compromise should a threat actor compromise the ISV environment. To minimize this risk, organizations should only keep the data they need to deliver services and not data that "may" be of use in the future. Additionally, data should only be kept for as long as is needed to provide the services the data was captured for. Data retention should be defined and communicated with users. Once data exceeds the defined retention period, this must be securely deleted so the data cannot be reconstructed or recovered.
Control No. 4
Please provide proof that an approved data retention period is formally established and documented.
Intent:
A documented and followed retention policy is important not only to meet some legal obligations, for example data privacy legislation such as, but not limited to, the General Data Protection Regulation (EU GDPR) and the Data Protection Act (UK DPA 2018) but also to limit an organizations risk. By understanding the organizations data requirements and how long data is needed for the business to perform its functions, organizations can ensure that data is properly disposed of once its usefulness expires. By reducing the volumes of data stored, organizations are reducing the amount of data that would be exposed should a data compromise occur. This will limit the overall impact.
Often organizations will store data because it’s nice to have just in case. However, if the organization does not need the data to perform its service or business function, then data should not be stored as this is increasing the organization’s risk unnecessarily.
The objective of this control is to confirm that the organization has formally established and documented an approved data retention period for all relevant types of data. This involves not only specifying the duration for which different types of data will be stored but also outlining the procedures for data deletion or archival post-expiration.
Guidelines:
Supply the full data retention policy which clearly details how long data (must cover all data types) should be kept for so the business can perform its business functions.
Example evidence:
The next screenshot shows Contoso's data retention policy.
Note: These screenshots show a snapshot of a policy/process document. The expectation is for ISVs to share the actual supporting policy/procedure documentation and not simply provide a screenshot.
Control No. 5
Demonstrate that data is retained only for the defined retention period as discussed in control 4.
Intent:
The intent of this control is to simply validate that the defined data retention periods are being met. As already discussed, organizations may have a legal obligation to meet this, but also by keeping data which is necessary and for as long as is necessary helps to reduce the risk to the organization should a data breach occur. This ensures that data is neither retained for an excessively long duration nor prematurely deleted, both of which could pose risks of varying nature—legal, operational, or security- related.
Guidelines:
Provide screenshot evidence (or via screenshare) showing that stored data (in all various data locations, including databases, file shares, archives, and backups) does not exceed the defined data retention policy. Examples of acceptable screenshots include:
- Database Records with a date field, searched in oldest record order, and/or
- File Storage Locations showing timestamps that are within the retention period. Note: Any personal or sensitive customer data should be redacted in the screenshot.
- Backup records showing that backup data is retained within the defined retention period and properly deleted after this period.
Example evidence:
The following evidence shows a SQL query showing the contents of the database table ordered in ascending order on the ‘DATE_TRANSACTION’ field to show the oldest records within the database. This shows that data is less than two months old which does not exceed the retention period defined.
Note: This is a test database, therefore there is not a lot of historical data within it.
Note: In the previous examples full screenshots were not used, however ALL ISV submitted evidence screenshots must be full screenshots showing URL, any logged in user and system time and date.
Control No. 6
Demonstrate processes are in place to securely delete data after its retention period.
Intent:
The intent of this control is to ensure that the mechanism used to delete data which exceeds the retention period is doing so securely. Deleted data can sometimes be recovered; therefore, the deletion process needs to be robust enough to ensure data cannot be recovered once deleted.
Guidelines:
If the deletion process is done programmatically, then provide a screenshot of the script that is used to perform this. If it is executed on a schedule, provide a screenshot showing the schedule. For example, a script to delete files within a file share may be configured as a CRON job, screenshot the CRON job showing the schedule and the script which is executed; and provide the script showing the command used.
Example evidence:
This is a simple script which could be used to delete all data records retained based on date -WHERE DateAdd is -30 days which will purge all retained records older than 30 days past the selected data retention date. Please note we will need the script; evidence of the job being run and the results.
Please Note: In the previous examples full screenshots were not used, however ALL ISV submitted evidence screenshots must be full screenshots showing URL, any logged in user and system time and date.
Example evidence:
The following screenshot has been taken from the Contoso Data Retention Policy (from Control 4) – This shows the procedures used for data destruction.
Note: This screenshot shows a snapshot of a policy/process document. The expectation is for ISVs to share the actual supporting policy/procedure documentation and not simply provide a screenshot.
Example evidence:
In this example a Runbook has been created and a corresponding schedule in Azure to securely delete records that have an end date created from the 30 days after expiry of the data record retention policy. This job is set to run every month on the last day of the month.
The next screenshot shows that the Runbook has been edited to find records and has delete commands not in view like the script.
Note: The full URL and username must be in view for these screenshots and ISVs will be required to show a screenshot of before deletion record count and a screenshot of after deletion record count.
These screenshots are purely examples of the different ways this can be approached.
Control No. 7
Please provide evidence demonstrating that:
An automated backup system is in place and configured to perform backups at scheduled times.
Backup information is tested in line with the backup scheduling procedure and restored periodically to confirm the reliability and integrity of the data.
Appropriate access controls and protection mechanisms (i.e., immutable backups) are implemented to ensure backups/ system snapshots are secured against unauthorized access and to ensure the confidentiality, integrity, and availability of the backup data.
Intent:
The objective of this control is to confirm that the organization has an automated backup system in place, which is configured to execute backups at predetermined times.
Guidelines:
Please provide screenshots of configuration settings from your backup solution showing that backups are being performed at scheduled periods/ intervals of time. If the backup scheduling is done by the solution automatically, this can be supported by providing vendor documentation.
Example evidence:
The following screenshot applies to the Azure Database for MySQL, which is a managed instance. It indicates that a first automated backup has been completed.
The next screenshot is taken after a period has passed shows that further full backups have been made. Backups on flexible servers are snapshot-based where the first snapshot backup is scheduled immediately after a server is created and further snapshot backups are taken once every day.
The next screenshot shows a snapshot of online documentation which outlines the backup frequency and the automated backup capability.
Intent:
The aim of this control is to substantiate that backup information is not only generated as per schedule but is also reliable and maintains its integrity over time. To meet this objective, periodic tests will be performed on the backup data.
Guidelines:
The evidence to meet this control will be dependent on the organization’s process and procedure for testing backup data. Evidence could be provided showing backups being successfully tested alongside records of historical testing completion.
Example evidence:
The following screenshot shows that a backup schedule and restore procedure exists and is maintained and that a backup configuration is defined for all applicable systems including frequency of backups being performed in the Confluence platform.
The next screenshot shows a page of historical records of backup testing for each of the systems applicable. Observe that on the right side of the table JIRA tickets are referenced for each of the tests.
The next four next screenshots show the end-to-end process of restoring the Azure Database for MySQL from a snapshot. Using the ‘Fast Restore’ option we can initiate the restore process of the SQL database.
The following screenshot shows the configuration page where we can customize the restore.
Once the target location, networking, and snapshot from which the database will be restored are selected we can initiate the deployment. Observe that our database instance is now called ‘test’.
After a total of five minutes the SQL database was successfully and fully restored from the backup snapshot as the following shows.
Once the testing was completed, in line with the process a JIRA ticket was created to record the backup testing and details of the restore performed. This ensures that historical data is available for compliance purposes as well as complete records exist for review in the eventuality of an incident or disaster to allow the organization to perform a root cause analysis.
Intent:
Leading on from the previous control, access controls should be implemented to limit access to only individual users who are responsible of the backup data. By limiting access, you are limiting the risk of unauthorized changes being carried out and thereby introducing insecure changes. A least privileged approach should be taken to protect the backups.
To properly protect data, organizations need to be aware of what data their environment / systems are consuming and where the data is being stored. Once this is fully understood and documented.
Organizations are then able to not only implement adequate data protection but are also able to consolidate where the data is located to implement protection more effectively. Additionally, when data is consolidated to as few places as possible, it is much easier to implement adequate RBAC (role- based access control) to limit access to as few employees as necessary.
Guidelines:
Evidence should be provided from the system/technology used demonstrating the access permissions to the backups and backup solutions with supporting documentation of approved access list.
Example evidence:
We can see in the following screenshots presented that access controls are implemented at the database instance to restrict access to only authorized individuals based on job role.
Example evidence:
Azure SQL Database and Azure SQL Managed Instances automated backups are managed by Azure and their integrity is a responsibility of the Azure platform; no user has access to them, and they are encrypted at rest with no possibility of ransomware attacks. They are also replicated to other regions for protection.
Data access management
Data access needs limiting to as few people as required to reduce the chances of data being either maliciously or accidentally compromised. Access to data and encryption keys should be limited to users with a legitimate business need for access to fulfil their job role. A well-documented and well-established process to request access should be implemented. Access to data and encryption keys should follow the least privilege principle.
Control No. 8
Provide evidence to demonstrate that a list of individuals with access to data and/or encryption keys:
is maintained including the business justification for each individual.
were formally approved based on access privileges required for their job function.
are configured with the privileges outlined in the approval.
Intent:
Organizations should limit access to data and encryption keys to as few employees as possible. The intent of this control is to ensure employee access to data and/or encryption keys are restricted to employees with a clear business need for said access.
Guidelines:
Documentation or screenshots of internal systems which document all employees with access to data and/or encryption keys along with the business justification of why these individuals have access should be provided. This list will be used by the certification analyst to sample users for the next controls.
Example evidence:
The following document shows the documented list of users with access to data and the business justification.
Note: This screenshot shows a policy/process document, the expectation is for ISVs to share the actual supporting policy/procedure documentation.
Intent:
The process for granting access to data and/or encryption keys needs to include approval, ensuring that an individual’s access is required for their job function. This ensures that employees without a genuine reason for access, do not get unnecessary access.
Guidelines:
Typically, the evidence provided for the previous control can help to support this control. If there is not a formal approval on the supplied documentation, then evidence may consist of a change request being raised and approved for the access within a tool such as, Azure DevOps or Jira.
Example evidence:
This set of images shows Jira tickets created and approved for the control (i) to grant or deny access to sensitive data and/or encryption keys. This image is demonstrating that a request has created in Jira to get Sam Daily approval for Encryption Keys on the systems backend environment. This is done as the next step where written authorization has been gained.
This shows that the request to give Sam Daily access has been approved by Jon Smith a person from management. (Please note approval must come from someone with sufficient authority to allow the change request, it cannot be another developer).
The previous shows a workflow in Jira for this process. Note that nothing can be added as Done unless it has been through the approval process which is automated and therefore cannot be bypassed.
The Project board is now showing that approval has been given for Sam Daily's access to encryption keys. The following backlog shows Sam Daily's request approval and the person assigned to do the work.
To meet the requirements of this control you must show all these screenshots or similar/equivalent evidence applicable with an explanation to demonstrate that you have met the control requirement.
Please Note: In the previous examples full screenshots were not used, however ALL ISV submitted evidence screenshots must be full screenshots showing URL, any logged in user and system time and date.
Example evidence:
In the next example, admin access and full control permissions have been requested for a user to the production DB. The request has been sent for approval as can be seen on the right of the image and this has been approved as shown on the left.
The next image indicates access has been approved and signed off as done.
Please Note: In the previous examples full screenshots were not used, however ALL ISV submitted evidence screenshots must be full screenshots showing URL, any logged in user and system time and date.
Intent
The intent of this subpoint is to confirm that data and/or encryption key access is configured as per documented.
Guidelines:
Evidence could be provided by way of screenshot which shows the data and/or encryption key access privileges granted to the sampled individuals. Evidence must cover all data locations.
Example evidence:
This screenshot shows the permissions granted to the user “John Smith” which would be cross
referenced against the approval request for this same user as per evidence for the previous control.
Please note: the following example is not a full screen screenshots, you will be required to submit full screen screenshots with any URL, logged in user and the time and date stamp for evidence review. If you are a Linux user this can be done via the command prompt.
Control No. 9
Provide evidence that:
A list of all third parties that data is shared with is maintained.
Data sharing agreements are in place with all third-parties consuming data.
Intent:
Where third parties are used for storage or processing of Microsoft 365 data, these entities can pose a significant risk. Organizations should develop a good third-party due diligence and management process to ensure these third parties are storing/processing data securely and to ensure they will honor any legal obligations that they may have, for example as a data processor under GDPR.
Organizations should maintain a list of all third parties with which they share data with some or all the following:
what service(s) is(are) being provided
what data is shared
why the data is shared
key contact information (i.e., primary contact, breach notification contact, DPO, etc.)
contract renewal/expiry
legal/compliance obligations (i.e., GDPR, HIPAA, PCI DSS, FedRAMP, etc.)
Guidelines:
Supply documentation detailing ALL third parties with which Microsoft 365 data is shared.
Note: If third parties are not in use, this will need to be confirmed in writing (email) by a member of the senior leadership team.
Example evidence:
Please Note: - In the previous examples full screenshots were not used, however ALL ISV submitted evidence screenshots must be full screenshots showing URL, any logged in user and system time and date.
Example evidence:
The following screenshot shows an email example of a member of the senior leadership team confirming no third parties are used to process Microsoft 365 data.
Please Note: - In these examples full screenshots were not used, however ALL ISV submitted evidence screenshots must be full screenshots showing URL, any logged in user and system time and date.
Intent:
Where M365 data is shared with third parties, it is important that data is being handled appropriately and securely. Data sharing agreements must be in place to ensure that third parties are processing data only as needed and that they understand their security obligations. An organizations security is only as strong as the weakest link. The intent of this control is to ensure that third parties do not become an organizations weak link.
Guidelines:
Provide the data sharing agreements that are in place with the third parties.
Example evidence:
The next screenshot shows a simplistic example of a data sharing agreement.
Note: The full agreement should be shared and not a screenshot.
Privacy
Privacy compliance and information management are essential for protecting individuals’ rights and ensuring responsible data handling. For an organization to establish an effective privacy information system, they require to be aware of what personal data they hold and the purpose for processing and storing such data. An organization should map the flow of information and how this is processed, recognizing that several different types of processing might be occurring.
Control No. 10 – Personal Data
Provide evidence that your organization:
A) Maintains an up-to-date inventory of all personal data collected, processed, and stored, including the purpose for each data element.
B) Designs data collection forms to include only fields that are necessary for the business purpose and implements mandatory and optional fields appropriately.
C) Develops and enforces policies that specify the types of personal data that can be collected and the purposes for which they can be used.
D) Lets users opt-out of processing or broad surfacing of their personal, non-business essential data.
Intent:
The intent of this control is to ensure you are adhering to data privacy concerned with the collection of data, ensuring there is a justification for the data being captured and to be transparent with what and why data is collected. It is also important that users (data subjects) have the ability to opt-out of processing.
Guidelines:
This control could be evidenced as follows:
A) Provide a current version of the organization's Record of Processing Activities (RoPA), (See GDPR Article 30) or similar document detailing the data elements, and the purpose(s) of processing (See GDPR Article 5.1.b).
In most cases, this would be an Excel spreadsheet (which could be extracted from tools, such as OneTrust).
If the file is too large or contains sensitive data, an excerpt could be provided, showing all of the data fields for a given sample of data, which can be partially redacted as long as the evidence can provide assurance that the RoPA is in place.
Non-compliant: The records do not exist, are very old/outdated, or are missing key fields.
B) For the purpose of ‘Data Minimization’ (See GDPR Article 5.1.c), provide all the forms used to obtain data, whether online, using tablets or similar devices (e.g. in a conference), or paper. These could be blank/templates.
Non-compliant: The forms have mandatory fields that are not necessary for the intended purpose of processing. For example, asking for telephone numbers, age, or gender, for sending a brochure via email or to a postal address.
C) For the purpose of ‘lawfulness, fairness and transparency’ (See GDPR Article 5.1.a) the Privacy Policy (intended for employees), the Privacy Notice (intended for users/customers) must be in place. Typically, the Privacy Notice should be publicly available on the organization’s website.
Non-compliant: The policies do not exist or are missing key elements.
Key elements:
Privacy Policy/Notice: information collection and usage, data elements processed, the purpose(s) of processing, the lawfulness of processing, data transfers to other countries, data subject rights, data storage and retention.
D) For the opt-out mechanism (See GDPR Article 4.11, GDPR Article 6, and GDPR Article 7), typically on a webpage. Check the navigation that the user would need to follow to get to that page (e.g. is it easy to find?).
Non-compliant: No clear opt-out functionality, or ‘generic’ opt-out, with no granularity.
Example evidence:
For A):
For B):
For C):
For D):
Control No. 11 – User Awareness
Provide evidence that users are aware of:
A) who has access to their data
B) who has access to the spaces they are working in
C) who could get access to their data through sharing or data flows so they can make informed decisions.
Intent:
The intent of this control is to demonstrate the data protection ‘Transparency’ principle (See GDPR Article 5.1.a) is met.
Guidelines:
To demonstrate this is in place ideally some form of user acknowledgment (e.g. to having read the Privacy Policy) should be in place and recorded.
In practice, just that the Privacy Policy (for employees), the Privacy Notice (for users and customers), provide sufficient details on the following:
- With whom personal data is being shared with (processors, sub-processors, third parties, contractors, etc.).
Non-compliant: No acknowledgements exist, or the Privacy Policy/Privacy Notice do not exist.
Example evidence:
OR
Control No. 12 – Data Processing Agreements (DPAs)
Provide evidence of the Data Processing Agreement, which should have a list of all approved 3rd parties / sub-processors.
Intent:
To ensure you are being transparent with the data subjects ensuring they are informed on which 3rd parties / sub-processors could have access to their data, the role they play in the processing (data controller, data processor), their respective responsibilities, and security mechanisms in place.
Also, when the sharing of data would involve data transfers to territories outside the EU (Under GDPR), details of the mechanism to ensure the transfers are lawful. (See GDPR Article 5 and GDPR Article 44-50)
For GDPR, the territories for processing must meet one of the following conditions:
- Be a European Union Member State.
- Be deemed by the European Commission to provide ‘adequate safeguards’. The current list can be found here: Data protection adequacy for non-EU countries
As of 13th June 2025:
- Be part of the Data Privacy Framework (DPF), and listed here: Data Privacy Framework
- Have Binding Corporate Rules (BCRs) in place.
- Have Standard Contractual Clauses (SCCs) in place.
Guidelines:
Evidence could be by way of sampling a couple of Data Processing Agreement (DPA) with existing sub-processors. In certain cases, organizations may not have DPAs, but would have addendums to contracts, or ‘Privacy Clauses’.
Non-compliant:
- The list of 3rd parties / sub-processors is missing.
- No details are given about the recipient countries.
- The countries are not listed as ‘adequate countries’, and there are no BCRs or SCCs in place.
Example evidence:
This example shows an example DPA from IAPP, or evidence could be a related document listing the parties with whom the data is shared.
In addition, check the mechanisms for data transfers outside the EU.
Control No. 13 – Data Protection Impact Assessments (DPIAs)
Provide evidence that your organization carries out Data Protection Impact Assessment (DPIA)
OR
Provide the name of the assessment related to data privacy and protection that this privacy review is connected to.
Intent:
The intent of this control is to ensure you are performing assessments on the potential risks to the rights and freedoms of individuals, especially related to the introduction of new technologies, or novel uses of existing technologies. (See GDPR Article 35)
Guidelines:
This control would be assessed by reviewing a recent DPIA, or related assessment documentation.
Non-compliant:
A DPIA should have the following elements:
- Identification of the need for a DPIA.
- Description of the envisaged processing, including scope, context, and purpose(s).
- Assessment of necessity and proportionality.
- Identification and assessment of risks.
- Identification of measures to reduce risk.
- Recorded outcomes.
If any of the above are missing, or just performed at a perfunctory level, this control can be marked as non-compliant.
Example evidence:
The full template of a DPIA can be found on the ICO’s website here dpia-template.docx
Control No. 14 – Biometric Data
Does the application interact with biometric data? If yes,
Provide evidence that biometric data has passed legal review, is protected and users are informed and given the option to opt-in/out of biometric data collection.
Intent:
This control is interested in ensuring adequate protections of biometric data, which under GDPR Article 9 is classified as a special category of data. The use of biometric data has undergone a lawfulness analysis.
Guidelines:
The use of biometric data must go through a legal review so this needs to be supplied as part of the evidence collection. If none exists, request the template that would be used (to check their readiness).
Non-compliant:
The legal review on the processing of biometric data should contain the following:
- Legal basis of processing (one or more of the following):
| Consent | Performance of a contract | Other legal obligation |
|---|---|---|
| Consent | Performance of a contract | Other legal obligation |
| Vital interests | Public interest | Legitimate interest |
- List a valid condition for processing biometric data (one or more of the following):
| Explicit consent from the user | Employment or social security |
|---|---|
| Explicit consent from the user | Employment or social security |
| Protection of vital interests | Legitimate activities |
| Personal data manifestly made public by the data subject | Establishment, exercise or defense of legal claims |
| Substantial public interest | Preventive or occupational medicine |
| Public interest in the area of public health | Archiving purposes in the public interest, scientific or historical research |
- Consideration given to the use of alternatives, instead of biometric data.
If any of the above are missing, or just performed at a perfunctory level, this control can be marked as non-compliant.
Example evidence:
Sources:
- GDPR Article 9 – Processing of Special Categories of Data: Art. 9 GDPR – Processing of special categories of personal data - General Data Protection Regulation (GDPR)
- ICO ‘How do we process biometric data lawfully?’: How do we process biometric data lawfully? | ICO
Control No. 15 – Data Insights
Provide evidence that metrics only show aggregated and anonymized data with no individually identifiable data. The tenant should be able to configure their preferred aggregation level lower limit, with an absolute minimum of 5 allowed by the product.
Intent:
The intent of this control is to ensure you have implemented and are maintaining the status of anonymized and pseudonymized data throughout the data life cycle. (See
Guidelines:
To help demonstrate this control is in place, evidence via GUI or CLI should be providing to demonstrate:
- User-level configuration for the lowest limits of aggregation levels.
- A sample of metrics.
Assess whether the user can configure a threshold for their preferred aggregation levels to a minimum of 5. The evidence should demonstrate that only anonymized is present in the sample of metrics.
Non-compliant:
- Users are not able to customize their aggregation levels to a minimum of 5, or the technical skill required to do so cannot be expected of the typical user.
- Personal data is present in the metric sample; for example: name, surname, ID, customer number, telephone number, email address, postal address, bank details, next of kin, etc.
Example evidence:
Screen captures of configuration settings, showing the specific details.
Sample of collected metrics. Perhaps ask about the process for achieving anonymization.
GDPR
Most organizations will be processing data that is potentially a European Citizen's (data subjects) data. Where data of ANY data subject is processed, organizations will need to meet the General Data Protection Regulation (GDPR). This applies to both Data Controllers (you're directly capturing said data) or Data Processors (you're processing this data on behalf of a Data Controller). Although this section does not cover the entire regulation, it addresses some of the key elements of GDPR to help obtain some assurance that the organization is taking GDPR seriously.
Control No. 16
Provide evidence demonstrating adherence to the rights of data subjects by showing:
A) Subject Access Request (SAR) facilitation:
Documentation that confirms data subjects are informed of their right to access their personal data and can submit Subject Access Requests (SARs) to your organization.
B) Data Discovery and SAR fulfilment:
Evidence of your organization's capability to locate and retrieve all personal data pertaining to an individual data subject across all systems and repositories in response to a SAR.
Intent:
The intent of this control is to ensure that adequate mechanisms are in place for data subjects to make requests about their personal data held by the organization, and that fulfilment of legitimate requests is thorough. (See GDPR Article 15).
Guidelines:
A) The Privacy Notice should contain details on how to make a SAR, which could be using of the following methods:
- Using a web form provided by the organization
- Using an email address provided by the organization
- Using a phone number/webchat provided by the organization
- Using a Supervisory Authority (e.g. the ICO in the UK)
Request evidence of the method in place; screen captures should be sufficient.
B) A RoPA or similar document can be used to identify the locations where the personal data pertaining to the data subject reside, whether digital or as part of filing systems (physical).
Alternatively, e-discovery exercises can achieve the same outcome.
Request evidence of the process/workflow that would be used to fulfil a SAR, and an explanation on how it was determined that the process is thorough and wouldn’t miss any personal data that relates to the data subject.
Non-compliant:
A) No information is provided on the organization’s website (typically in the Privacy Notice).
B) Evidence indicates the process to gather the personal data is not thorough or may lack technical detail (e.g. no names/locations given for databases).
Example evidence:
A) The following are examples of what evidence could be provided to cover point A).
– Web form:
Source: Subject Access Request - Police Care UK
- Email address/phone number:
Source: Which? Privacy Policy - Which?
- Webchat:
Source: Make a subject access request to HMRC - GOV.UK
- Via a Supervisory Authority (e.g. the ICO):
Source: Make your subject access request | ICO
B) Supplied evidence artefacts Detailing workflows or process descriptions with sufficient technical detail, that could plausibly be used to fulfil the SAR.
Control No. 17
Provide the Privacy Notice which should contain all the required elements as follows:
A) The identity and contact details of the organization, and Data Protection Officer (DPO), if applicable.
B) The personal data types your organization handles (name, surname, customer number, email address, telephone number, etc.). Also, the personal data sources (e.g. where the personal data comes from), in case the organization has not obtained it directly from the data subjects.
C) The purpose(s) of processing personal data.
D) The lawful basis of processing personal data (including legitimate interests where relevant).
E) Parties your organization shares personal data with.
F) Details of how long personal data will be kept for.
G) Details of data subjects’ rights:
Right to be informed
Right of access
Right to rectification
Right to erasure
Right to restriction of processing
Right to data portability
Right to object
Rights in relation to automated decision-making, including profiling
H) The details regarding any transfer of personal data to a third country and the safeguards taken.
I) The right to lodge a complaint with a supervisory authority, providing contact details of the supervisory authority (e.g. the ICO in the UK).
Intent:
The intent is to ensure the published Privacy Notice contains sufficient detail by including the above elements and principles, pursuant to GDPR Chapter 3.
Guidelines:
As per Control 10.c whereby you must publish a Privacy Notice that is covering the service included within the Microsoft 365 Certification. This Privacy Notice must contain the elements and principles highlighted above.
Non-compliant:
Refer to Control 10.c.
Example evidence:
Refer to Control 10.c.
HIPAA (Health Insurance Portability and Accountability Act)
The Health Insurance Portability and Accountability Act of 1996 (HIPAA) is a federal legislation applicable to American citizens and healthcare organizations. It is important to note that this legislation also covers any organizations outside of the US that process healthcare data of American citizens. The introduction of the legislation mandated the Secretary of the U.S. Department of Health and Human Services (HHS) to develop regulations protecting the privacy and security of certain health information. Some organizations may process data that is potentially protected health information (ePHI), which means individually identifiable health information transmitted by electronic media, maintained in electronic media, or transmitted or maintained in any other form or medium. Where health data of ANY data subject is processed, organizations will need to meet HIPAA.
HIPAA has two pieces of legislation that need to be considered: ‘The Privacy Rule’, or Standards for Privacy of Individually Identifiable Health Information, which outlines the national standards for the protection of certain health information, and ‘The Security Standards’ for the Protection of Electronic Protected Health Information also referred to as the ‘Security Rule’. The latter establishes a national set of security standards for protecting certain health information that is held or transferred in electronic form.
From a high-level overview, ‘The Security Rule’ is a practical implementation of the protections offered by the ‘Privacy Rule’. It outlines the technical and non-technical measures that “covered entities” must implement to ensure the security of individuals’ “electronic protected health information” (e-PHI). Although this section does not cover the entire regulation, it addresses some of the key elements of HIPAA to help obtain some assurance that the organization is meeting compliance with the requirement and that the organization is safeguarding the health information that it processes.
Control No. 18
Please provide demonstratable evidence that:
A policy exists for HIPAA and HIPAA handling within your organization for staff, contractors etc.
ISV is ensuring the confidentiality, integrity, and availability of ePHI that it creates, receives, maintains, or transmits.
Protect against any reasonably anticipated threats and hazards to the security or integrity of ePHI.
Intent:
The intent of this subpoint is to ensure that organizations have established protocols that serve as standard procedures for managing health information, dealing with emergencies and service disruptions, and staff access to health information and training. Additionally, organizations are expected to maintain and outline these administrative safeguards as part of their HIPAA security program. This is a crucial aspect of complying with HIPAA regulations.
Guidelines:
This would be evidenced by supplying the organization’s established documentation outlining the HIPAA policy and procedure. Certification analysts will review this to ensure that all the information provided within the control is addressed.
Example evidence:
The screenshots show snapshots of a HIPAA policy. Please Note: The expectation is for ISVs to share the actual supporting policy/procedure documentation and not simply provide a screenshot.
Note: The expectation is for an ISV to share the actual comprehensive supporting policy/procedure documentation and not simply provide a screenshot.
Intent:
In order to understand the intent of this subpoint and ensure compliance with the Security Rule, “covered entities” must first know how the terms for confidentiality, integrity and availability are defined under § 164.304:
Confidentiality: “the property that data or information is not made available or disclosed to unauthorized persons or processes.”
Integrity: “the property that data or information have not been altered or destroyed in an unauthorized manner.”
Availability: “the property that data or information is accessible and useable upon demand by an authorized person.”
The intent of this requirement is that the organizations implement technical safeguards/measures such as access, audit, integrity, and transmission controls within the IT infrastructure to ensure ePHI confidentiality while maintaining its integrity and availability to authorized users.
Guidelines:
Evidence may be provided by way of configuration settings of the protection mechanisms used to ensure that ePHI data is secured in line with the control requirement. Such mechanisms can include access controls, emergency access procedures, RBAC, encryption etc.
Example evidence: access and integrity controls
The next screenshot shows that an authorized access list of individuals who have permissions to handle ePHI storage locations exists and is maintained within the HIPAA policy document. Additionally, in the screenshots following the approved inventory list, it can be observed that there is limited write access across the cluster with only the administrator and database maintenance analyst being able to read and write on the cluster.
The next screenshot taken from one of the ePHI storage databases in Atlas Mongo demonstrates that only authorized users have the access documented and that all accounts have unique user IDs to ensure accountability.
The first screenshot shows the main storage location/ database cluster for ePHI.
The second screenshot demonstrates that the approved users only have the roles and access documented.
The next two screenshots show a more granular view of each of the roles assigned and all associated permissions which are in line with the access approval above.
Each custom role has a set of permissions and scope of access.
Finally, the next screenshot demonstrates from a networking perspective, that only the authorized IP range which is the secure corporate network is allowed access to the cluster.
Example evidence: audit controls
These screenshots show logging and alerting is implemented for the database cluster. The first screenshot shows that alerts are enabled. Please note that the expectation is that the evidence supplied also shows the alert rules that were set based on the organization’s need/ implementation. The second screenshot shows database auditing is being enabled.
The next screenshot shows the access history to the database cluster being recorded. The expectation is that alerts are set and based on the audit logs and any unauthorized access not meeting the pre- defined conditions will trigger an alert.
The final two screenshots show that audit logs are generated for the database cluster and that logs can be exported for analysis.
Please note the expectation is that there is a process in place for the audit logs generated to be analyzed, evidence of the review process must also be supplied. If this is achieved programmatically, screenshots of configuration settings of the log ingestion into the platform / logging solution used, as well as screenshots of the rules must be provided for review.
Example evidence: encryption and transmission controls
The next screenshots demonstrate that the storage location has data at rest encrypted by default. Please note that if encryption is not performed by the platform used by default and your own encryption keys are in use, then the expectation is that those keys are adequately secured, and evidence is provided to demonstrate this.
The next two screenshots demonstrate that the storage location has data in transit encrypted by default. The first screenshot demonstrates that a data API is enabled with ‘read and write’ permissions.
An SSL scan of the endpoint demonstrates that data in transit is encrypted via TLS 1.2.
Example evidence: availability and recovery controls
The next screenshot demonstrates that the database cluster is replicated across three regions to ensure availability. This is done by default by Mongo Atlas. Additionally, backup is enabled and is active.
The following screenshot shows the backup dashboard of the cluster which also demonstrates that a snapshot has already been created.
The next two screenshots demonstrate that a backup policy is in place to perform scheduled backups at different points in time (PIT).
The following indicates there is a retention policy for both snapshots and point in time restore (PIT).
Intent:
The intent of this subpoint aligns with the security rule which was developed to ensure flexibility and scalability so that a “covered entity” can implement policies, procedures, and technological solutions that are fit for purpose for the entity’s size, its organizational structure, and their specific risks as well as their appetite for risk. From a practical perspective this means that the appropriate security measures implemented will depend on the nature of the “covered entity’s” business, as well as its size and resources.
It is vital for every organization to conduct a comprehensive risk analysis to uncover potential risks and vulnerabilities to the confidentiality, integrity, and availability of e-PHI. Through this risk analysis, organizations can then implement appropriate security controls to mitigate these identified risks.
Guidelines:
Evidence may be provided by way of risk analysis output. Where the risk analysis is performed and maintained via an online platform, screenshots of the entire output should be provided.
Example evidence:
The next screenshots show snapshots of the risk assessment process, followed by the risk analysis which was performed to determine the extent to which controls are implemented correctly and operating as intended to protect ePHI. The second screenshot shows a risk analysis for the risks identified in the risk assessment and the compensating controls and mitigations implemented to decrease the level of risk.
Example 1 – Snapshot of the risk assessment process within the HIPAA policy and risk analysis performed
Note: This screenshot shows a snapshot of a risk analysis document, this is just an example, and the expectation is for ISVs to share the actual documentation and not simply provide a screenshot.
Example 2 – Screenshots of risk assessment process within the HIPAA policy and risk analysis performed (Maintained in the Confluence Cloud Platform)
The second screenshot shows a risk analysis for the risks identified in the risk assessment and the compensating controls and mitigations implemented to decrease the level of risk. We can see this exists and is maintained in the Confluence cloud platform.
Control No. 19
Please provide evidence that you (ISV):
Protects against reasonably anticipated uses or disclosures of such information that are not permitted by the Privacy Rule; and
Ensure compliance with the Security Rule by its workforce.
Data backup and Disaster recovery plan under 164..308 (a)(7)(ii)(A) and 164.308 (a)(7)(ii)(B).
Intent
The Privacy Rule defines what pieces of Protected Health Information (PHI) are covered by the law and prohibits improper uses and disclosures of PHI. The intent of this subpoint is that an organization must limit the access and use of e-PHI to only those who need it for authorized purposes and that they must comply with the minimum necessary rule, which requires them to use or disclose only the minimum amount of e-PHI necessary to accomplish their intended purpose.
A combination of technical and administrative safeguards must be in place to restrict the use of ePHI and to ensure the risk of disclosure of the ePHI is decreased.
Guidelines:
Evidence supplied needs to show the technical safeguards in place such as technologies and mechanisms that are in use to protect e-PHI and how the organization controls check the access and movement of such data.
Example evidence:
The next screenshots show Microsoft Purview Data Loss Prevention (DLP), which is an integrated platform that allows organizations to manage their DLP policies from a single centralized location.
You can observe below that a “U.S. HIPAA Enhanced” policy is enabled, this provides the ability to prevent users from pasting sensitive data to specific websites, including personal email, generative AI prompts, social media sites, and more when accessed through a supported web browser.
The next screenshot provides a more comprehensive overview of the policy including the scope that it is applied to. The policy is set to all accounts in locations such as SharePoint, Devices, OneDrive, etc.
When selecting the option to “Edit Policy” a more granular view into the specific configurations available is displayed.
The next two screenshots show the content definition and conditions that must be met for the policy to be applied.
The policy covers various sensitive data types as well as a set of classifiers.
The next section shows the actions configured to be taken when the conditions shown in the previous screenshots are met.
The following screenshot shows that the DLP policy is set to prevent their users from copying and pasting sensitive information such as personally identifiable information (PII) from the organization’s internal databases into their personal email accounts, chatbots, and social media sites on supported browsers.
Finally, user notifications are configured to notify and provide guidance to users as they are handling ePHI data.
The following screenshot shows the configuration panel for generating alerts when an incident occurs.
Intent:
The intent of this subpoint is that an organization must train their staff on how to handle e-PHI securely and appropriately, and that they must enforce policies and procedures to ensure compliance with the Security Rule.
Guidelines:
Evidence supplied needs to demonstrate that HIPAA training is performed on how to handle ePHI and that records of attendance and training completion exist. Where applicable this can be supported by policy documentation and training materials used.
Example evidence:
The examples following show the potential evidence that can be submitted to demonstrate that appropriate HIPAA training occurs in line with the policy.
The next screenshot shows a snapshot of the HIPAA policy with a specific section outlining the requirement for training. Please note this is just an example and not a comprehensive document/implementation, the expectation is that the ISV will have an established process that is applicable to their organization.
Example 1 – HIPAA User Training via Administrative Process
In the next screenshot the course overview slide shows a summary of the course objectives. If training is built in house then the training materials must be supplied for review, please note that the complete material must be submitted and not just a screenshot of the summary.
The following screenshot shows the attendance record for the employees that participated in the training. The record also shows the pass score as well as the next training scheduled date.
The second example demonstrates how Microsoft 365 Defender can be used to set and launch training campaigns.
Example 2 – HIPAA user training via the Microsoft 365 Defender Attack Simulation Platform (All users)
The previous screenshot shows the HIPAA Security training campaign, total duration in minutes, as well as the completion status. The next screenshot provides an overview of the users that the training was assigned to and the training status which demonstrates successful completion.
Example 3 – HIPAA User Training via the Microsoft 365 Defender Attack Simulation Platform (Individual user)
While the previous example focused on demonstrating that all users completed the annual training campaign, the final example shows targeted evidence demonstrating completion for one employee.
You can observe in the two previous screenshots that as soon as the training campaign was launched, every employee received an email confirming the training assignment and due date, as well as the modules assigned, duration, etc.
Using the link available in the email notification, the following screenshot shows the Training Assignments page for the user and the two modules which have now been completed.
Intent:
Under the HIPAA Security Rule, a data backup plan and a disaster recovery plan are mandatory for any “covered entity” that handles electronic protected health information (ePHI). Such plans are part of the contingency strategy that aims to ensure the availability and security of ePHI in case of an emergency or other occurrence that damages the systems that contain ePHI.
The intent of the data backup plan is to create and maintain retrievable identical copies of ePHI, this should also include periodic testing of the backups to ensure the recovery of data is possible. The intent of the disaster recovery plan is to restore any potential lost data in the event of a disaster, and this should specify the steps that must be taken to restore access to data, including how files should be restored from backups.
Guidelines:
Please provide the full version of the disaster recovery plan/procedure which should cover the backup plan and the recovery plan. Supply the actual PDF/Word document if in a digital version, alternatively if the process is maintained through an online platform provide a PDF export or if unable to export due to limitations of the platform, please supply screenshots covering the entire policy.
Example evidence:
The next screenshot shows snapshots of the HIPAA Security Policy containing an overview of the general and high-level backup procedure and Disaster Recovery plan.
Note: This screenshot shows a snapshot of policy/process document, this is just an example, and the expectation is for ISVs to share the actual comprehensive supporting policy/procedure documentation and not simply provide a screenshot.
Books
Murdoch D. (2018) Blue Team Handbook: Incident Response Edition: A condensed field guide for the Cyber Security Incident Responding Responder. 2nd Edition, Publisher: CreateSpace Independent Publishing Platform.
References
Action Fraud Cyber Crime reporting Available at: https://www.actionfraud.police.uk/ (Accessed: 12/10/2023).
EU. (2021) GDPR Checklist for data controllers Available at: https://gdpr.eu/checklist/ (Accessed: 12/10/2023).
Microsoft. (2018) Event Logging (Windows Installer) Available at: Event Logging (Accessed: 03/05/2024).
Positive Technologies. (2020) How to approach secure software development Available at: https://www.ptsecurity.com/ww-en/analytics/knowledge-base/how-to-approach-secure- software-development/(Accessed:12/10/2023).
Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation) (Text with EEA relevance) (2016) Available at: https://www.legislation.gov.uk/eur/2016/679/contents (Accessed: 12/10/2023).
Security Metrics. (2020) Security Metrics Guide to PCI DSS Compliance. Available at: https://info.securitymetrics.com/pci-guide-2020(Accessed: 12/10/2023).
Williams J. OWASP Risk Ranking Available at: https://owasp.org/www- community/OWASP_Risk_Rating_Methodology (Accessed: 12/10/2023).
Qualys. (2014) SSL Labs: New Grades for Trust (T) and Mismatch (M) Issues Available at: https://blog.qualys.com/product-tech/2014/06/17/ssl-labs-new-grades-for-trust-t-and- mismatch-m-issues (Accessed: 12/10/2023).
NIST SP800-61r2: Computer Security Incident Handling Guide Available at: https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final (Accessed: 12/10/2023).
Creating a CI/CD pipeline with Azure Pipelines and Google Kubernetes Engine | .NET
Google Cloud (Accessed: 10/10/2023).
The Disaster Recovery Plan at: https://www.sans.org/white-papers/1164/ (Accessed: 10/10/2023).
https://github.com/ (Accessed: 10/10/23).
Security Policy Templates at: https://www.sans.org/information-security-policy/ (Accessed: 10/10/23).
https://www.openedr.com/ (Accessed: 02/10/23).
https://www.atlassian.com/software/confluence (Accessed: 10/10/23).
https://www.atlassian.com/software/jira (Accessed on 28/09/23).
Business Continuity Plan (BCP) Table Top Exercise Template at: https://www.pivotpointsecurity.com/services/business-continuity-management/table-top- exercise-template/ (Accessed: 10/10/23).
Summary of the HIPAA Security Rule | HHS.gov (Accessed: 18/10/2023).
Health Information Privacy Laws in the Digital Age: HIPAA Doesn't Apply - PMC (nih.gov) (Accessed: 18/10/2023).
What is the Purpose of HIPAA? Update 2023 (hipaajournal.com) (Accessed: 18/10/2023).
What is Considered PHI under HIPAA? 2023 Update (hipaajournal.com) (Accessed: 18/10/2023).
HIPAA Policies and Procedures (hipaajournal.com) (Accessed: 18/10/2023).
Designing HIPAA Policies & Administrative Policies | Dash Solutions (dashsdk.com) (Accessed: 18/10/2023).
45 CFR § 164.304 - Definitions. | Electronic Code of Federal Regulations (e-CFR) | US Law | LII
/ Legal Information Institute (cornell.edu) (Accessed: 18/10/2023).
What Is HIPAA Compliance? HIPAA Laws & Rules | Proofpoint UK (Accessed: 18/10/2023).
HIPAA Security Rules, Regulations and Standards (training-hipaa.net) (Accessed: 18/10/2023).
Summary of the HIPAA Security Rule | HHS.gov (Accessed: 18/10/2023).
SP 800-66 Rev. 1, An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule | CSRC (nist.gov) (Accessed: 18/10/2023).
The Security Rule | HHS.gov (Accessed: 18/10/2023).
https://www.hipaajournal.com/hipaa-encryption-requirements (Accessed: 19/10/2023).
https://www.hipaajournal.com/hipaa-privacy-rule/ (Accessed: 19/10/2023).
https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html (Accessed: 19/10/2023).
https://www.tausight.com/the-ultimate-guide-to-electronic-protected-health-information- ephi/ (Accessed: 19/10/2023).
Configure Encryption — MongoDB Manual (Accessed: 19/10/2023).
https://its.ucsc.edu/policies/docs/hipaa-risk-analysis.doc (Accessed: 19/10/2023).
Microsoft Purview Data Loss Prevention: Announcing general availability of several capabilities
Microsoft Community Hub (Accessed: 24/10/2023).
45 CFR § 164.308 - Administrative safeguards. | Electronic Code of Federal Regulations (e-CFR)
| US Law | LII / Legal Information Institute> (cornell.edu) (Accessed: 24/10/2023).
When should we provide privacy information? | ICO (Accessed: 08/11/2023).
How should we draft our privacy information? | ICO (Accessed: 08/11/2023).
Accountability Framework | ICO (Accessed: 08/11/2023).
ISO 27001 Requirement 5.1 - Leadership & Commitment | ISMS.online (Accessed: 08/11/2023).
Online Browsing Platform (OBP) (iso.org) (Accessed: 08/11/2023).
Clause 5.3 Organizational Roles, Responsibilities and Authorities - ISO Training (Accessed: 08/11/2023).
5.3 Roles, Responsibility and Authority (iso9001help.co.uk) (Accessed: 08/11/2023).
De-identification and re-identification of PII in large-scale datasets using Sensitive Data Protection | Cloud Architecture Center | Google Cloud (Accessed: 08/11/2023).
De-identifying sensitive data | Sensitive Data Protection Documentation | Google Cloud (Accessed: 08/11/2023).
A guide to data security | ICO (Accessed: 08/11/2023).
International data transfers | ICO (Accessed: 08/11/2023).
Records management and security | ICO (Accessed: 08/11/2023).
ISO 27701 - Privacy Information Management (Accessed: 08/11/2023).
ISO 27701 Privacy Information Management System (PIMS) | ISMS.Online (Accessed: 08/11/2023).
Images/text taken from Microsoft Documents
https://www.sans.org/information-security-policy/ (Accessed: 18/02/21).
Get behavioral analytics and anomaly detection (Accessed:03/05/24).
What are Azure Monitor alerts? (Accessed:03/05/24).
(Accessed:03/05/24).
Manage and respond to security alerts in Microsoft Defender for Cloud (Accessed:03/05/24).
Manage and respond to security alerts in Microsoft Defender for Cloud (Accessed:03/05/24).
https://microsoft.github.io/AzureTipsAndTricks/blog/tip272.html (Accessed: 09/10/23).
Transparent data encryption for SQL Database, SQL Managed Instance, and Azure Synapse Analytics (Accessed:03/05/24).
Quickstart: Create a policy assignment to identify non-compliant resources (Accessed:03/05/24).
Configure Advanced Threat Protection for Azure SQL Database (Accessed:03/05/24).
Backup and restore in Azure Database for MySQL - Flexible Server (Accessed:03/05/24).
Certificate inventory (Accessed:03/05/24).
Backup and restore in Azure Database for MySQL (Accessed:03/05/24).
https://github.com/microsoft/presidio/blob/main/docs/samples/deployments/data- factory/presidio-data-factory-template-gallery-http.md (Accessed: 08/11/2023).