Security domain: data handling security and privacy
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 the various data locations, i.e., databases, file shares, archives, etc.) does not exceed the defined data retention policy. Examples could be screenshots of:
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/sensitive customer data should be redacted within the screenshot.
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
Does your organization have a Privacy Information Management (PIM) system established, implemented, and maintained that:
Holds leadership commitment by way of a policy or other form of documentation/computerized system for how your privacy information management efforts are maintained for system confidentiality and integrity.
Determines roles, responsibilities and authorities of each person maintaining the system, including PII Processors and Controllers.
Intent:
The intent of this point is to ensure that a ‘culture of privacy’ exists and is supported by the organization’s leadership through an effective privacy governance program. The organization’s management must demonstrate via their established documentation and processes that there is an effective privacy management system, said processes are aligned with the organization’s strategic goals and are established within the organization’s context and circumstances, as well as ensure that the privacy management system is embedded within the business processes.
Guidelines:
This would be evidenced by supplying the organization’s established documentation outlining the Privacy Information Management (PIM) policy and procedure. Certification analysts will review this to ensure that all the information provided within the control is addressed.
Example evidence:
The following screenshots show snapshots of a PIM policy.
Please Note: The expectation is for ISVs to share the actual supporting policy/procedure documentation and not simply provide a screenshot.
Intent
Accountability is one of the key principles in data protection law as it enables an organization to minimize the risks associated with their handling of personal data by implementing appropriate and effective policies, procedures, and processes. These measures must be proportionate to the risks, which can vary depending on the amount of data being handled or transferred, its sensitivity and the technology in use. To achieve this, each employee must know who is responsible for the various elements of the privacy management system to ensure successful implementation. By having an established documentation outlining the roles, responsibilities, and authorities in a clearly defined manner, and having those roles assigned appropriately, an organization can ensure that their privacy management system is effective.
Guidelines:
This would be evidenced by supplying the organization’s established documentation outlining the roles, responsibilities, and authorities of each relevant person. Certification analysts will review this to ensure that all the information provided within the control is addressed.
Example evidence:
The next screenshots show snapshots of a PIM policy showing a section of the policy containing the approved employee’s list.
Please Note: The expectation is for ISVs to share the actual supporting policy/procedure documentation and not simply provide a screenshot.
Control No. 11
Provide evidence of processes to show that:
PII minimization is taking place.
PII de-identification and deletion is being done at the end of the processing period.
Controls are in place for PII transmission including any confidentiality.
Record of transfer of PII from one country/region to another exists with expressed consent to do so.
Intent: PII
The intent of PII (Personally Identifiable Information) minimization is to ensure that an organization collects, uses, and retains only the minimum amount of personal data necessary to achieve a specific purpose within the organization’s context and within the business justification. When handling personal data, an organization has to identify what is the least amount of data that is required to achieve that goal/task and ensure that no more than that minimum data required is being stored. By minimizing the processing and storing of unnecessary personal data an organization ensures that the level of risk associated with data misuse, unauthorized access and data breaches is reduced.
Guidelines: PII
Evidence may be provided by way of configuration settings of the solution used to minimize personal information usage if this is done via an automated platform, or if a manual administrative process, then evidence of the minimization process and evidence of records of the process occurring should be supplied to the analyst for review.
Example evidence: PII
The following screenshot shows that a reccurring monthly meeting is scheduled where all new data received within the organization within that period is reviewed and where applicable, any personal information that is deemed unnecessary is removed.
In the next screenshot is an example of a filled in user registration form used to onboard new customers within the platform.
The subsequent screenshot demonstrates that based on the PII minimization meeting and review, it was deemed that some of the sensitive information that was collected within the form is no longer needed to provide the service back to the user. In the next image, the PII of the referees have been removed, as well as the email address (the expectation is that each organization will have a business justification for holding or removing that information).
Please note: The previous is an example of one potential scenario. It is by no means comprehensive and when supplying evidence, the process for minimizing PII should be clearly demonstrated and should apply to the specific context of the organization.
Intent: data privacy
The intent of this subpoint is multifaceted and covers several techniques and different concepts but the overall goal is for an organization to be compliant with data protection regulations by ensuring that data privacy across the organization is enhanced.
Starting with de-identification, which is the process of removing specific information that can be used to identify an individual from data, the intent is to ensure that any information that is deemed sensitive, such as email address, date of birth etc., is changed/converted (through various techniques such as pseudonymization or masking) into a format that renders it unusable to directly link it to an individual. The purpose of this process is not just to preserve the utility of the data but also to ensure the level of risk associated with data misuse, unauthorized access, and data breaches is reduced.
Organizations should define data retention and delete unnecessary data at the end of the processing period. Once data exceeds the defines data retention period, it must be securely deleted to ensure that it cannot be reconstructed or recovered. Keeping data that is necessary and for as long as 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: data privacy
Evidence may be provided by way of configuration settings of the mechanism and/or technique used to ensure that PII data anonymized and deleted in line with the control requirement.
Example evidence: data privacy
The example shown in the next screenshots uses the built in data anonymization template of Azure Data Factory which is a part of the Template Gallery and allows us to move a set of text files from one location to another while anonymizing their content. It shows that a data factory in Azure exists for PII anonymization.
The next screenshot shows the configuration of the PII anonymization pipeline. It leverages the code for using Presidio on Azure App Service to call Presidio as an HTTP REST endpoint in the Azure Data Factory pipeline while parsing and storing each file as an Azure Blob Storage.
The following screenshot shows the pipeline steps and logic.
The final screenshot demonstrates a successful run of the pipeline to anonymize PII.
Please note: The previous is an example of one potential scenario. It is by no means comprehensive and when supplying evidence, the process for anonymizing PII should be clearly demonstrated and should apply to the specific context of the organization.
Example evidence: data privacy
The following screenshot demonstrated an example of addressing the deletion of PII at the end of the processing period by enabling a Lifecycle management policy for the storage account in Azure where PII is held.
The next screenshot demonstrates that the retention is set for a predefined period after which the data is deleted automatically.
Please note: The previous is an example of one potential scenario. It is by no means comprehensive and when supplying evidence, the process for deleting PII data and the specific retention period applicable should be clearly demonstrated and should apply to the specific context of the organization.
Example evidence: data privacy
The final screenshot demonstrates that a data lifecycle management retention policy is in place for PII data transfer and storage across various locations within the organization, such as SharePoint, OneDrive, devices, mailbox, etc. This policy is enabled using Microsoft Purview. The retention policy is configured to automatically delete any PII once the predefined retention period has elapsed.
Please note: The previous is an example of one potential scenario. It is by no means comprehensive and when supplying evidence, the process for deleting PII data and the specific retention period applicable should be clearly demonstrated and should apply to the specific context of the organization.
Intent: controls
The intent of this subpoint is to ensure that organizations have appropriate technical and administrative/operational safeguards in place to protect PII during processing and transmission. The emphasis on confidentiality refers to securing data from unauthorized access and disclosures through technical and administrative controls such as encryption of the data at rest and in transit, documented access control lists and regular auditing.
Guidelines: controls
Evidence may be provided by way of configuration settings of the protection mechanisms used to ensure that PII data is protected in line with the control requirement. Such mechanisms can include access controls, RBAC, encryption, data loss prevention, etc.
Disclaimer: The examples presented show a few potential scenarios where controls are applied to ensure PII is protected. Please note that the type of protection mechanisms in place will be dependent on your organization’s context and how PII is used, stored, etc.
Example evidence: Encryption
The following examples show encryption of PII at storage location where PII is being held and encryption during transit via the web application/platform where users input personal information which is stored in the application’s backend.
The 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.
Second screenshot shows that TLS1.2 is enforced in transit for the application where PII is collected.
Example evidence: access controls
The following screenshot demonstrates from a networking perspective, that only the authorized/ approved IP range which is the secure corporate network is allowed access to the PII storage location.
The next screenshot shows an example of Azure PIM and the user list with the eligible assignments. By using just-in-time (JIT) access, it allows users to gain temporary access to a privileged role or resource for a limited amount of time which decreases the risk of a privileged user being compromised or introducing changes to the environment, data locations, etc.
Example evidence: PII transmission and disclosure prevention
These 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.K. PII Data” policy is enabled. This provides the ability to prevent users from providing sensitive data to specific websites, including personal email, generative AI prompts, social media sites, and more when accessed through a supported web browser. This ensures that risk of potential confidentiality breaches or unauthorized disclosures of PII by employee is decreased as all workplace devices/users have the organizational policy applied.
The next screenshot(s) provides a 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.
The screenshot previous and following shows that the DLP policy is set to prevent 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.
Intent: records
The intent of this subpoint is twofold; it ensures that effective record management is in place to facilitate data governance and data protection while it ensures legal compliance and accountability as transferring personally identifiable information across different countries involves navigating different legal requirements. Before initiating a PII transfer an organization must ensure that they have explicit consent from the data subject(s) to whom it belongs, said individual(s) must be informed about the transfer, the purpose of the transfer and the associated risk. The record of the consent being obtained will validate the authorization of the transfer. The record of the transfer(s) should also contain additional details of the transfer, risk assessment, data protection impact, and retention period.
Guidelines: records
The evidence that can be provided for records of PII transfers and records of expressed consent will depend on how the transfer process and record management is implemented at the organization level. This can include whether the consent is obtained through a platform, terms, and conditions of the service, or via forms of consent filled in by each user. Evidence supplied must show that historical records of the transfers completed over a period exists and how this is tracked, as well as records of explicit consent being obtained.
Example evidence: records
The next screenshot shows an example of a filled in consent form by one of the users of the organization’s services. We can see that explicit consent, acknowledgment, and understanding of the conditions was provided by the user.
The following screenshot shows that a historical record of PII transfers exists and includes details of the specific PII data that is being exchanged, the purpose of the transfer, the origin country, the destination country, protection of the data in transit, approval, etc.
Please note: The previous is an example of one potential scenario, it is by no means comprehensive and when supplying evidence, the process for transferring PII data, record management, etc. should be clearly demonstrated and should apply to the specific context of the organization.
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. 12
Provide evidence demonstrating that:
Data subjects are able to raise SARs.
Validate that you (the ISV) are able to identify all locations of data subjects' data when responding to a SARs request.
That there is a retention period for backups which allows clients requesting removal of data via SARs to be removed as rolling backups over a period are removed (lifecycle of oldest back up deletions/rewritten over).
Intent:
GDPR includes specific obligations that must be met by organizations processing data subjects’ data. The obligation for organizations to manage Subject Access Requests (SARs) is included within Article 12 which, under Article 12.3, gives a data controller one month from receiving the SAR to respond to the request. An extension is permitted for a further two months where necessary and only if there is justification to do so. Even if your organization is acting as a Data Processor, this will still be needed to help your customers (the Data Controller) fulfil their SARs obligations.
Guidelines:
Please supply the documented process for handling SARs. Example evidence:
The following example shows a documented process for handling of SARs.
Note: This screenshot shows a policy/process document, the expectation is for ISVs to share the actual supporting policy/procedure documentation.
Intent:
The intent of this control is to ensure the organization has a robust mechanism in place to identify all data subjects’ data. This may be a manual process because all data storage is well documented, or other tooling may be used to ensure all data is located as part of the SARs process.
Guidelines:
Evidence may be provided by way of a list of all data locations and a documented process to search all data locations for data. This would include any necessary commands to search for data, i.e., if SQL locations are included, then specific SQL statements would be detailed to ensure data is found properly.
Example evidence:
The next screenshot is a snippet from the previous SAR’s procedure which shows how data will be found.
The four images following show how the ISV data locations were queried, and Storage Explorer was used to drill down to the files or blob that needed to be removed from storage to comply with the SARs request.
Note: that 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.
This query confirms the storage accounts in use. You can query and remove storage, blobs and/or files using Resource Graph Explorer (Kusto) or PowerShell (see next).
Please Note: - For the examples in this section full screenshots were not used, however ALL ISV submitted evidence screenshots must be full screen screenshots showing URL, any logged in user and system time and date.
The next image shows the data that has been found within the blob container for the client which needs to be removed and the following shows the action to delete or soft delete the information in the blob.
Please note: that the 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.
Intent:
The objective of this control is to demonstrate that a formal retention period exists for backups, designed in a manner that accommodates the removal of data pursuant to SARs. The retention framework should allow for the phasing out of older backups over a defined period, ensuring that any data removed due to a SAR is ultimately erased from all backups. This is critical for aligning the organization’s backup and data retention practices with obligations arising from SARs, thus fulfilling regulatory requirements concerning the right to erasure.
Guidelines:
Evidence may be provided by way of a screenshot showing backup configuration settings demonstrating the period and methodology with which backups are performed. The emphasis should be on the backup frequency period.
Example evidence:
The following screenshot is a snippet of configuration settings from the Azure database for MySQL which is a managed instance.
We can see in the screenshot that the backup retention period is set for 28 days.
Based on the backup section we know that backups on flexible servers are snapshot based with the first snapshot backup is scheduled immediately after a server is created and further snapshot backups are taken daily once.
The 28 days backup retention combined with the backup frequency means that when a SAR is fulfilled, the rolling backup will continue for maximum of 27 days rolling and decreasing as enforced by the retention period until all that user data is removed.
Control No. 13
Please provide the privacy notice which should contain all the required elements as follows:
Entities details (Name, Address, etc.)
Details of the type of personal data being processed.
Details how long personal data will be kept for.
Details of the lawfulness of processing personal data.
Details of data subject's rights:
Right to be informed
Right of access by the data subject
Right to erasure
Right to restriction of processing
Right to data portability
Right to object
Rights in relation to automated decision-making, including profiling
Intent:
Article 13 of GDPR includes specific information that must be provided to data subjects at the time when personal data is obtained. The intent of this control is to ensure the organizations data privacy notice provides data subjects with some of the key information included within Article 13.
Guidelines:
This would usually be provided by supplying the data privacy notice. Certification analysts will review this to ensure all the information provided within the control is included within the data privacy notice.
Example evidence:
The next screenshots show snapshots of a privacy policy.
Please note: that 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.
The images of a Privacy Notice show an example of an online privacy policy with Article 13 of GDPR included.
Following is a Data Protection Policy which can be used in conjunction with the privacy notice shown previously.
The previous image of Azure shows how Azure has been configured to meet the compliance requirements of GDPR for data stored in a backend environment. The policy (which can be custom made or built from Azure Blueprints) allows the ISV to ensure that client’s data is stored correctly and that it is accessible only by the specified metrics. Also, alerts are set to ensure compliance and will show noncompliant data or user access on the compliance manager dashboard.
Please note: that the previous 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.
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. 14
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. 15
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 inhouse 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.restore.co.uk/Records/Services/Magnetic-Tape-Storage (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).
https://www.iow.nhs.uk/Downloads/Policies/Business%20Continuity%20Policy.pdf (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).
Principle (c): Data minimization | ICO (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).