Quantifying Website Privacy Posture Through Technical and Policy-Based Assessment

Abstract

With the rapid growth of digital interactions, safeguarding user privacy on websites has become a critical concern. This paper introduces a comprehensive framework that integrates both technical and policy-based factors to assess a website’s level of privacy protection. The framework employs a scoring system that evaluates key technical elements, such as HTTP security headers, email authentication protocols (SPF, DKIM, DMARC), SSL/TLS certificate usage, domain reputation, DNSSEC, and cookie practices. In parallel, it examines the clarity and GDPR compliance of privacy policies. The resulting score reflects not only the technical strength of a website’s defenses but also the transparency with which data processing practices are communicated to users. To demonstrate its effectiveness, the framework was applied to two similarly sized private hospitals, generating comparative privacy scores under a unified metric. The results confirm the framework’s value in producing measurable insights that enable cross-organizational privacy benchmarking. By combining policy evaluation with technical analysis, this work addresses a significant gap in existing research and offers a reproducible, extensible methodology for assessing website privacy posture from a visitor’s perspective.

1. Introduction

Privacy-enhancing technologies for websites remain a critical concern for all internet users. The rapid growth of the internet has been accompanied by serious concerns about user privacy. Personally Identifiable Information (PII) can be easily exposed if adequate technical safeguards are not in place to protect websites from various malicious activities. As we proposed in our previous work [1], assessing online privacy policies is an important first step toward evaluating website privacy. Indeed, online privacy policies have become increasingly important in safeguarding personal information; today, more than ever, end-users must carefully consider whether to accept the terms and conditions presented to them. Indicatively, research has indicated that privacy notices often lack effective design elements to assist users in understanding terminology such as “opt-in” or “opt-out” options [2]. Several research efforts have suggested summarizing key information and developing visualization tools to enhance users’ understanding of privacy policies [3].

However, beyond reviewing privacy policies, it is equally important to examine the presence of technical measures to establish a comprehensive privacy framework for websites. Several techniques have been explored in earlier studies. For example, Johan Mazel et al. [4] proposed a set of website characteristics such as HTTP requests, domain names, and third-party requests. Amelia et al. [5] introduced a scoring system ranging from A to E, which primarily focuses on the presence or absence of HTTPS and the referrer policy in web application headers. Adrian Dabrowski et al. [6] highlighted privacy concerns based on previous research and online survey data. Ronghao Pan et al. [7] discussed website analysis tools that help validate the protection of users’ PII. Furthermore, data privacy is widely recognized as a fundamental right. Organizations handling Personal Identifiable Information (PII) must ensure robust security for all user transactions. For e-commerce and online transactions, real-time monitoring for data breaches is essential to strengthen security and build customer trust [8]. In addition to financial transactions, many websites allow users to provide feedback regarding products or services they have received. In these situations, the website should ensure that user feedback is not linked to other personal information. Social media platforms also enable users to buy and sell products, generating a significant amount of data beyond what is contained in user profiles [9]. Numerous studies have highlighted the ambiguity surrounding data collection and processing practices on social media platforms [10]. It is recommended that these platforms revise their data sharing permissions and ensure users are informed about privacy settings and authentication mechanisms. Web tracking techniques frequently collect diverse types of information, often without obtaining explicit user consent. For instance, the referrer header (an HTTP request header) transmits data from previously visited URLs [11]. Additionally, malicious scripts can be injected into web pages through cross-site scripting (XSS) attacks, and then executed within the user’s browser, potentially compromising sensitive information. Collectively, these efforts present various approaches for safeguarding information and assessing privacy risks on websites.

To develop a holistic privacy framework for website evaluation, we go beyond the online privacy policy assessment previously discussed in our earlier work [1]. We introduce a scoring system based on technical measures to assess privacy protection. Various technical aspects are considered, depending on the architecture and implementation of each website. To the best of our knowledge, no existing research has specifically focused on evaluating email implementation and domain name protection in the context of website privacy. Our ultimate goal is to integrate the findings from the technical privacy evaluation with the results of the online privacy policy assessment in order to create a browser extension to showcase the privacy posture of visited websites.

Finally, we present a unified scoring system for website privacy evaluation that incorporates all selected technical indicators along with the privacy policy analysis. This approach generates quantifiable results, enabling easy comparison between the privacy practices of two or more similar organizations.

2. Methodology

In this section, we present a comprehensive methodology that provides a structured framework for comparing privacy protection levels across a wide range of websites. Our approach encompasses the most critical privacy-oriented factors, each carefully selected and supported by a clear rationale. We also detail the scoring system used to evaluate these factors.

We begin by analyzing web application headers. Beyond this, our evaluation extends to the use and configuration of cookies, examining the data they collect and their respective roles. We also assess the measures in place for secure email provision and evaluate the implementation and robustness of website certificates.

Furthermore, our methodology includes an assessment of technical defenses against phishing and domain squatting. To support a thorough analysis, we have compiled an extensive set of supplementary criteria, including analytics services, CMS technologies, authentication mechanisms, and other relevant elements.

Below, we outline the essential technical measures that website administrators should consider for ensuring the highest level of user privacy:

• Web Applications Headers
  • Content-Security-Policy (CSP)
  • Strict-Transport-Security (HSTS)
  • Referrer-Policy Header
• Email security
  • Sender Policy Framework
  • DomainKeys Identified Mail
  • Domain-based Message Authentication, Reporting & Conformance
• Certificates
• Phishing Domains and Squatting Domains
• Reputation domain score
• DNSSEC
• Cookies
• Privacy Policy

2.1. Web Applications Headers

HTTP headers are an integral part of the HTTP protocol, which serves as the foundation of the World Wide Web (WWW). These headers carry metadata that define how HTTP communication between a client and server is established and managed. They play a crucial role in determining the behavior of both servers and clients.

In the following sections, we will focus on HTTP headers that directly influence user security and privacy. As previously noted, there are various types of HTTP headers depending on their intended function. For the purposes of this research, we concentrate on the categories of web application headers that impact the protection of user data. Based on the literature [12,13,14,15,16,17], the most commonly used web application headers relevant to this context are listed below:

• Access-Control-Allow-Origin Security Header
• Content-Type Header
• Content-Security-Policy (CSP)
• Cross-Origin-Embedder-Policy Security Header
• Cross-Origin-Resource-Policy Security Header
• Cross-Origin-Opener-Policy Security Header
• Set-Cookie Header
• Strict-Transport-Security (HSTS)
• Referrer-Policy Header
• X-Content-Type-Options Security Header
• X-Frame-Options Security Header
• X-Permitted-Cross-Domain-Policies Security Header
• Cache-Control Header
• X-Powered-By Header

Our privacy evaluation framework focuses on three web application headers (the headers highlighted in bold above) that are widely recognized for their strong emphasis on user privacy. It is important to note that cookie-related headers are excluded, as cookies will be examined separately. The automated verification process for the used headers is also fairly simple using the python requests library.

2.1.1. Content-Security-Policy (CSP)

The first header is the Content-Security-Policy (CSP). CSP headers are designed to mitigate and detect cross-site scripting (XSS) attacks as well as clickjacking attempts. Without a properly implemented CSP header, attackers may be able to inject and execute malicious scripts, potentially stealing personal data or redirecting users to fraudulent websites. It is the responsibility of the website administrator to determine the most appropriate CSP configuration. The policy’s syntax can vary widely, depending on the types and sources of content that are permitted to load and execute on the website. Additionally, the X-XSS-Protection header, which was historically used to prevent XSS attacks, is generally considered obsolete in modern browsers—especially when a robust Content-Security-Policy is already in place to disable unsafe inline JavaScript.

2.1.2. Strict-Transport-Security (HSTS)

The second web application header included in our framework is Strict-Transport-Security (HSTS). This header instructs the browser to access the website exclusively via the HTTPS protocol, thereby enforcing secure communication between the client and the server. The use of HTTPS is essential for safeguarding data in transit and plays a critical role in preventing attacks such as cookie hijacking. Similarly to the Content-Security-Policy (CSP) header, the HSTS header allows for flexible syntax configurations, depending on the specific security policy the website administrator aims to implement.

It is also important to note that for HTTPS communication to be effective, the website must use a valid SSL/TLS certificate issued by a trusted certificate authority. Self-signed certificates are insufficient, as they do not provide the same level of trust and can undermine the security guarantees offered by HSTS.

2.1.3. Referrer-Policy Header

The third web application header included in our framework is the Referrer-Policy header. This header controls how much referrer information—such as the URL of the previous webpage or the source of a redirect—is included when navigating between sites. Because referrer data can potentially expose sensitive information, it is essential to configure this header with appropriate values, such as no-referrer, to mitigate privacy risks. Moreover, major browsers like Microsoft Edge and Google Chrome have announced plans to further strengthen user privacy by phasing out third-party cookies, reinforcing the importance of properly configured referrer policies.

There are several free online tools available to evaluate how a domain has implemented its web application headers—such as “Analyze your HTTP response headers” [18]. Alternatively, these headers can be inspected manually through browser developer tools. For example, in Google Chrome, web application headers can be viewed by following the next steps (see Figure 1):

• Right-click anywhere at the domain.
• Select the option “Inspect”.
• From the development tools choose the Network tab.
• Refresh the page.
• Choose any HTTP request to find the way headers are implemented.

The evaluation of CSP/HSTS/Referrer-Policy headers is performed according to the acceptance criteria listed in Appendix A.2.

2.2. Email Security

The second technical measure included in our framework is email security. Email remains one of the most common attack vectors for cybercriminals seeking to exploit sensitive information, posing risks to both organizations and individual recipients. Given the near-universal use of email accounts and the reliance of most companies on email for internal and external communication, addressing these vulnerabilities is critical. While not a privacy issue itself, poor email configuration can lead to a privacy loss from employees of the organization, external vendors, or users that fall for well-crafted malicious emails that are spoofed in a manner that would fool even technologically literate users that check the sender address. A combination of social engineering and exploitation of poor email security can lead to loss of privacy through the loss of security. Numerous studies have highlighted that a significant proportion of emails—approximately 70%—include confidential information [19]. Furthermore, today, more than ever before, most internet users share personal information—such as identity card numbers or bank account details—via email. Additionally, according to surveys 72% of employees would share sensitive or confidential company information without adequate data security protocols in place [19]. To effectively protect user privacy and ensure the confidentiality of email exchanges, the implementation of robust technical safeguards is essential. In particular, there are three key mechanisms within the email infrastructure that can substantially enhance the security and privacy of email communications [20].

• Sender Policy Framework
• DomainKeys Identified Mail
• Domain-based Message Authentication, Reporting & Conformance

All three protocols rely on DNS records for their operation allowing us to easily verify their implementation, according to the acceptance criteria listed in Appendix A.1.

2.2.1. Sender Policy Framework

One widely adopted security measure for protecting email communication is the implementation of the Sender Policy Framework (SPF) protocol (Figure 2). SPF enhances email authenticity by verifying that incoming messages originate from authorized IP addresses associated with the sender’s domain. This verification process helps prevent common email-based attacks such as phishing and spoofing.

An SPF record, published in a domain’s DNS, explicitly lists the IP addresses that are permitted to send emails on behalf of that domain. When a mail server receives an incoming message, it checks the sender’s IP against this record. If the IP is not listed, the server takes action based on the receiving organization’s defined policy—typically rejecting the message or flagging it as suspicious.

By correctly deploying SPF, organizations can strengthen email security, protect recipients from fraudulent messages, and preserve their domain’s reputational integrity.

2.2.2. DomainKeys Identified Mail

Like SPF, DomainKeys Identified Mail (DKIM) is a protocol designed to safeguard email communications from fraudulent activities such as spoofing and tampering (Figure 3). DKIM utilizes asymmetric cryptography—specifically, a pair of private and public keys—to generate cryptographic signatures that verify the authenticity of email senders.

When an email is composed, the sender selects specific header fields to be signed using their private key. This results in a DKIM signature, which is then included in the email headers. Upon receipt, the recipient’s mail server retrieves the sender’s public key—published in the domain’s DNS records—and uses it to decrypt and verify the DKIM signature. The verification process involves matching the decrypted signature to the original header values, ensuring that the message has not been altered in transit and that it originated from an authorized source.

Organizations that utilize third-party email service providers can configure their DKIM settings, accordingly, ensuring that the signature validation process remains accurate and secure.

2.2.3. Domain-Based Message Authentication, Reporting & Conformance

Finally, it is essential to highlight the role of Domain-based Message Authentication, Reporting, and Conformance (DMARC) in strengthening email security (Figure 4). DMARC is an email authentication protocol specifically designed to combat phishing and email spoofing. One of its key functions is to verify the alignment between the MAIL FROM and FROM addresses, ensuring that both originate from the same domain [21].

DMARC builds upon the results of SPF and DKIM, using their authentication outcomes to inform the receiving mail server on how to handle incoming messages. While SPF and DKIM validate whether an email was sent from an authorized source and remains unaltered, DMARC enforces a domain owner’s policy on how to treat emails that fail these checks. Depending on the organization’s specified DMARC policy, the recipient server can choose to accept, quarantine, or outright reject such emails.

By implementing DMARC, organizations not only gain greater control over the handling of unauthenticated messages but also benefit from detailed reporting features that provide visibility into potential abuse of their domain.

2.3. Website Certificates

Another critical metric in our framework is the use of website certificates. Organizations must protect a wide range of online transactions from malicious activities. For example, they may collect information through online forms, allow users to create accounts, or enable services such as online shopping and booking. Given the diversity of user interactions, it is essential to secure online transactions and safeguard personally identifiable information.

Website certificates play a vital role in this process by establishing secure communication between web servers and web browsers. In addition, it is important to ensure that all cookie transactions between the server and browser occur over a secure channel using valid certificates. To be effective, website certificates must be:

• Valid and up to date
• Issued by a trusted Certificate Authority (CA)
• Generated using a strong signature algorithm

These measures are fundamental to maintaining user trust and protecting sensitive data [22,23].

We are planning to implement a tool based on the functionality of https://github.com/ssllabs/research/wiki/SSL-Server-Rating-Guide (accessed on 4 August 2025) to verify the proper usage of certificates for the use on our privacy score calculation.

2.4. Phishing Domains and Squatting Domains

Cybercriminals frequently employ deceptive tactics such as creating mirror websites—fraudulent copies of legitimate sites—to mislead users and steal sensitive information. These fake portals can seriously damage an organization’s reputation. By tricking users into entering confidential data like usernames and passwords, attackers gain unauthorized access to systems and personal information. Additionally, some fraudulent websites may deliberately publish false or misleading content to further harm the target organization.

This deception is often executed by registering domain names that closely resemble the legitimate ones, making them easy to confuse. For example, if an organization uses the domain “onlineuniversity.gr”, a criminal might register “onlineuniversity.com” to mislead users. Another common technique involves substituting similar-looking characters—such as using the number 0 in place of the letter o—resulting in a fraudulent domain like “0nlineuniversity.gr”.

To mitigate such threats, domain owners should adopt proactive defense strategies. A common approach is to purchase the same domain name across multiple top-level domains (TLDs), such as .com, .net, or .org, to prevent misuse by attackers. One such tool that could collect this data is the open source tool dnstwist (https://github.com/elceef/dnstwist (accessed on 8 August 2025)). Based on the output from that tool we can calculate the percentage of phishing and squatting domains relative to the visited domain and calculate them as a percentage of available domains to calculate the privacy risk, normalized in a 0–5 range. Additionally, website administrators can employ technical countermeasures, such as the use of canonical tags in their HTML code. The canonical tag helps identify the original source of content and can signal duplicate content issues, thereby alerting administrators if someone attempts to replicate their website. Tools that analyze a website’s source code can verify the presence and configuration of this tag.

2.5. Reputation Domain Score

Another key technical measure integrated into our privacy framework is the domain reputation score. This score reflects the security posture of a web domain, based on the proactive steps taken by an organization or company to protect its online presence.

Numerous platforms have been developed to evaluate and score domain reputations using well-defined metrics. These typically include factors such as:

• Hosting location
• IP address range associated with the domain
• Historical involvement in malware-related activities
• Presence of downloadable files with executable or suspicious code
• Overall domain history and behavior

These metrics are used to generate a reputation score that helps determine whether a domain is safe or potentially harmful. Several tools conduct real-time evaluations of domain reputation and often produce comparable classification results by relying on common assessment criteria, the most common ones being the following [24]:

URL category	Presence of downloadable files or code
Age of a URL	Previous association with malicious internet objects
History of a URL	Current association with malicious internet objects
IP reputation	Hosting location

In constructing our framework, we reviewed a wide array of domain scoring and validation systems. Among the platforms examined were:

• FortiGuard Lookup [24]
• Comprehensive Threat Intelligence [25]
• MxToolbox [26]
• VirusTotal [27]
• BarracudaCentral.org—Technical Insight for Security Pros [28]

Following a comparative review of these tools, we found that the most frequently utilized criteriοn is the: “No prior history of involvement in malware-related activities”.

2.6. Domain Name System Security Extensions (DNSSEC)

Another important technical component of our online privacy framework is DNSSEC (Domain Name System Security Extensions). DNSSEC significantly enhances privacy and security by enabling the authentication of DNS data, which helps detect and prevent DNS-based attacks such as cache poisoning or spoofing.

DNS data for each domain name is stored within a DNS zone, which resides on a name server on the Internet. To secure this data, DNSSEC uses asymmetric cryptography, involving a public key and a private key for each DNS zone. The zone owner uses the private key to digitally sign the DNS data, generating a cryptographic signature that validates the integrity and authenticity of the data. The corresponding public key is published within the DNS zone itself. When a user or system queries DNS information from that zone, the response includes this public key. The recipient can then use the key to verify the digital signature, ensuring that the DNS data has not been altered or tampered with [29].

By enabling such verification, DNSSEC strengthens user trust and contributes to a more resilient and privacy-focused internet infrastructure. DNSSEC provides indirect support for privacy by ensuring the authenticity of DNS data. It can also be used together with DNS over TLS (DoT), which encrypts DNS queries. Again, like in the case of email above, DNSSEC is not a privacy enhancing technology but through the improvement of the security posture of the domain, privacy is enhanced as a result.

2.7. Cookies—Cookie Policy

The final metric in our framework is cookies. It is necessary to understand the difference between the cookie policy and the privacy policy. Cookie policy outlines the tracking technologies used by websites to enhance user experience and gather information about user preferences and actions. Cookie implementation can vary rapidly and frequently, so the cookie policy should always be updated.

Different types of cookies collect various kinds of information. Some are essential for website functionality, while others are utilized for advertising and analytics purposes [30]. Many websites now use Consent Management Platforms (CMPs). CMPs are software tools that provide websites with required functionality and ensure compliance with privacy regulations such as GDPR [31], ePrivacy [32], and other legislations. These platforms inform users about the personal information that may be collected and give them options to decide. Additionally, Google [33] has established a group of partners with certified CMPs, categorizing them into three levels: Bronze, Silver, and Gold.

In our metric, we aim to understand how cookies function on different occasions. Furthermore, we will assess the quantity, purpose, and duration of the cookies, along with their compliance with privacy regulations. The long-term aim is to evaluate the cookie policy through the use of either a comprehensive list of known cookies and their uses or through the use of a dedicated lightweight LLM that runs on the user’s browser to assess the compliance and privacy-oriented nature of the cookie policy. This will occur in the scope of an upcoming paper dedicated to both cookie policy and privacy policy evaluation through LLM using lightweight models. The quantification of the privacy score will be addressed in the upcoming paper, however it will be on a scale of 0–10.

2.8. Privacy Policy

As we proposed in our previous work [1], assessing online privacy policies is an important first step toward evaluating website privacy. More specifically [1] introduces a GDPR-based framework designed to help users compare privacy policies across various sectors, addressing the challenge of determining which policies offer the strongest data protection. The framework extends existing research by providing a methodology that quantifies online privacy policies, thereby facilitating their assessment and thus offering a more structured and measurable approach to evaluate the compliance and effectiveness of privacy policies in protecting user data. The quantification of the privacy policy compliance for the privacy score calculation will be addressed in the aforementioned paper, however it will be addressed on a scale of 0–50.

3. A Framework for Website Privacy Evaluation

The framework that we propose for evaluating how “privacy friendly” and secure a website is, combines the technical parameters that should be assessed (Section 2.1, Section 2.2, Section 2.3, Section 2.4, Section 2.5, Section 2.6 and Section 2.7) and the privacy policy (Section 2.8) of the website.

The proposed privacy framework introduces a scoring system which is based on:

• The importance of each technical parameter in terms of how significantly it can impact the level of privacy protection on the website (for example, the consequences of a misconfigured cookie implementation are different from those of using a harmful domain—reputation score);
• The extent to which the website’s users are properly informed about the processing of their personal data (what data is collected, the purpose of the processing, whether their data is shared with third parties, how long the data is retained, how they can exercise their rights, etc.).

While we acknowledge that the majority of the parameters used for the calculations focus primarily on security, we argue that they play an important role in the protection of the user’s privacy in the context of an external observer/user who wishes to grasp an estimate of the organization’s privacy posture, with regard to how much care has been put into technical security measures. The framework considers a Boolean check of the implementation of each measure (Implemented/Not Implemented) and if a measure is deemed as implemented then the corresponding measure adds one to the overall privacy score calculation.

Thus, the maximum points that can be collected from each category is:

• Web Applications Headers (P1): 6 (scoring range from 0 to 6)
• Email security (P2): 6 (scoring range from 0 to 6)
• Certificates (P3): 9 (scoring range from 0 to 9)
• Phishing Domains and Squatting Domains (P4): 10 (scoring range from 0 to 10 (based on a percentage of found squatting domains))
• Reputation domain score (P5): 6 (scoring range from 0 to 6)
• DNSSEC (P6): 3 (scoring range from 0 to 3)
• Cookies (P7): 10 (scoring range from 0 to 10)
• Privacy Policy (P8): 50 (scoring range from 0 to 50)

with the overall privacy score being calculated as:

$$\mathit{P}\mathit{r}\mathit{i}\mathit{v}\mathit{a}\mathit{c}\mathit{y} \mathit{S}\mathit{c}\mathit{o}\mathit{r}\mathit{e} = P1+P2+P3+P4+P5+P6+P7+P8 (Scoring range from 0 to 100)$$

The highest possible privacy score that a website can achieve is 100. There are four distinct classes representing the privacy posture, as outlined in

Table 1. Privacy Classes.

Level	Total Privacy Score	Description
Poor	0–25	Minimal or no privacy protections in place.
Low	25–49	Basic measures are present, but significant gaps remain.
Moderate	50–74	Adequate protection, though improvements are still needed.
Good	75–100	Strong privacy posture with comprehensive measures in place.

.

As already discussed, evaluating a website’s privacy from the perspective of an external observer can be challenging and requires going beyond simply reviewing the cookie policy and privacy policy. Our proposed framework considers security measures both at the website and domain level, ensuring that the site is built with sufficient safeguards that, in turn, strengthen privacy. Most of this evaluation can be automated by using a combination of open-source and commercial tools to check for the presence of the specified security measures. For cookie and privacy policies, recent advances in large language models (LLMs) can be leveraged to automatically assess their contents (see: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3208596 (accessed on 8 August 2025)).

At present, the proposed framework is not tool-assisted. However, a browser extension is under development with the goal of automatically generating an accurate privacy score. The extension will integrate open-source tools running locally along with lightweight, on-device LLMs to evaluate cookie and privacy policies. This approach aims to strengthen user privacy and maintain anonymity across visited sites, managed by a single entity. Finally, the overall privacy score will be presented using a color-coded scale (red < 25%, orange < 50%, yellow < 75%, and green ≥ 75%).

As a case study, we have used the proposed framework to evaluate the websites of two private hospitals of similar size (Hospital A and Hospital B), both in terms of their privacy policies and the technical parameters presented in this paper. It should be noted that the evaluation of the privacy policies of the two hospitals is described in detail in [1].

Table 2. Weighted scoring system.

Category	Maximum Score	Scoring Range	Sub-Scoring
Web Applications Headers (P1)	6	0 to 6	Award two points for each of the three Web application headers that is implemented. Content-Security-Policy (CSP) Strict-Transport-Security (HSTS) Referrer-Policy Header
Email security (P2)	6	0 to 6	Award two points for each of the three email security features that are implemented. SPF DKIM DMARC
Certificates (P3)	9	0 to 9	Points are awarded as follows: 4 points: Certificate from a trusted Certificate Authority 3 points: Certificate is valid 2 points: Strong signature algorithm
Phishing Domains and Squatting Domains (P4)	10	0 to 10	Award five points if dnstwist results are satisfactory. Award five points if technical measures are in place (use of canonical tags, ensure that the same domain name is used consistently across multiple top-level domains, including .com, .net, or .org, to block deceptive tactics such as mirror websites that copy legitimate sites.
Reputation domain score (P5)	6	0 to 6	Award six points if there is no prior record of malware-related activity.
DNSSEC (P6)	3	0 to 3	Award three points if DNSSEC has been deployed
Cookies (P7)	10	0 to 10	Each of the following criteria will be evaluated using a scoring range from 0 to 2. Transparency Consent Necessity & Minimization Ability to withdraw consent. Easy access to change cookie preferences.
Privacy Policy (P8)	50	0 to 50	Award five points for each of the ten criteria required for full compliance (according to the Privacy Policy Evaluation Rubric presented in Appendix B)

provides a weighted scoring system that accounts for privacy risks, accompanied by a sub-scoring table outlining the evaluation process for each parameter.

The scoring of each parameter for each hospital is presented in

Table 3. Evaluation of the two Hospitals.

		Hospital A	Hospital B
Technical Parameters	Web Applications Headers	2	2
	Email security	4	4
	Certificate	5	9
	Phishing Domains and Squatting Domains	10	10
	Reputation domain score	6	6
	DNSSEC	0	0
	Cookies	4	8
Total Technical Privacy Score		31	39
Privacy Policy Parameters	Records of Data Processing Activities (DPA) (GDPR Article 30)	4	4
	General requirement for Third—party data transfer (TPD) (GDPR Articles 44–50)	4	2
	Data Protection Management System (PMS) (GDPR Article 24)	2	4
	Data Protection Impact Assessment (PIA) (GDPR Articles 35–36)	3	4
	Data Subject Rights (DSR) (GDPR Articles 12,15,16)	4	3
	Data Protection by default and design (PDD) (GDPR Article 25)	3	2
	Data Breach Notification (DBN) (GDPR Articles 33–34)	5	2
	Technical and Organizational Measures (TOM) (GDPR Article 32)	2	4
	Codes of Conduct & Certifications (CCC) (GDPR Articles 40–43)	4	4
	Data Protection Contact Information (PCI) (GDPR Articles 13,14)	5	3
Total Privacy Policy Score		36	32
Final Privacy Score		67	71

, while the comparative evaluation of the websites of the two hospitals is also illustrated graphically in Figure 5.

It is important to note that although Hospital A scores higher than Hospital B in Privacy Policy, Hospital B ultimately achieves the highest overall score and emerges as the winner. Furthermore, it is important to highlight that Hospital B ranks higher than Hospital A in both Technical and Organizational Measures derived from Privacy Policy Parameters, as well as in the overall technical privacy score.

In addition, Hospital B demonstrates higher ratings in both its Data Protection Management System and Data Protection Impact Assessment when evaluated against privacy policy criteria. These results appear also to correlate with an elevated Total Technical Privacy score. Consequently, it can be concluded that robust technical implementation on a website may effectively mitigate privacy risks, even if the associated privacy policy is rated poorly or lacks clarity. Our research significantly contributes by examining how privacy policy interacts with technical implementation. By integrating the evaluation of privacy policies with technical features, we have developed a framework that facilitates standardized privacy audits and highlights specific vulnerabilities, such as invalid certificates or insufficient email protection. The following section provides a justification of the scores assigned to each parameter for both hospitals.

Web Applications Headers (P1): 6 (scoring range from 0 to 6)

Hospital A has implemented the Content-Security-Policy header; however, the implementation is not secure, and HTTP traffic does not redirect to HTTPS. Hospital B, on the other hand, has yet to implement the Content-Security-Policy header, and similarly, HTTP traffic does not redirect to HTTPS. Both hospitals have correctly configured the Referrer-Policy header.

• Web Applications Headers Score for Hospital A: 2
• Web Applications Headers Score for Hospital B: 2

Email security (P2): 6 (scoring range from 0 to 6)

Both hospitals have implemented SPF and DKIM policies. However, neither has put a DMARC policy in place.

• Email security Score for Hospital A: 4
• Email security Score for Hospital B: 4

Certificates (P3): 9 (scoring range from 0 to 9)

Hospital A has one asset with an untrusted certificate, while all assets at Hospital B use valid certificates.

• Certificate Score for Hospital A: 5
• Certificate Score for Hospital B: 9

Phishing Domains and Squatting Domains (P4): 10 (scoring range from 0 to 10 (based on a percentage of found squatting domains))

Both hospitals secured the same domain name on multiple TLDs, applied canonical tags to their websites, and received satisfactory dnstwist results.

• Phishing Domains and Squatting Domains Score for Hospital A: 10
• Phishing Domains and Squatting Domains Score for Hospital B: 10

Reputation domain score (P5): 6 (scoring range from 0 to 6)

Both Hospitals gain the same score according to our evaluation equal to 6.

DNSSEC (P6): 3 (scoring range from 0 to 3)

There are no DNSSEC signatures (DS records) for any hospital domains visible in public tools or domain metadata.

• DNSSEC Score for Hospital A: 0
• DNSSEC Score for Hospital B: 0

Cookies (P7): 10 (scoring range from 0 to 10)

In our case study, the number of cookies that are not necessary for the website’s operation is significantly higher in case A than in case B.

• Cookies Score for Hospital A: 4
• Cookies Score for Hospital B: 8

Privacy Policy (P8): 50 (scoring range from 0 to 50)

• Privacy Policy Score for Hospital A: 18
• Privacy Police Score for Hospital B: 16

Thus, the privacy score for both Hospitals is Moderate (Hospital A: 67%, Hospital B: 71%).

4. Comparative Analysis

Previous research has introduced several methods for evaluating user privacy during website browsing. Nevertheless, these studies have not simultaneously incorporated both policy-level privacy assessments and comprehensive technical parameters. Furthermore, the technical parameters examined in prior work are limited and differ significantly from those defined in the Privacy Framework proposed herein.

Table 4. Comparative Analysis.

Technical Parameters and Privacy Policy Metrics	Ref. [11] Combating Web Tracking: Analyzing Web Tracking Technologies for User Privacy	Ref. [5] Evaluating Websites and Their Adherence to Data Protection Principles: Tools and Experiences	Ref. [4] A Comparison of Web Privacy Protection Techniques	Ref. [34] PolicyGPT: Automated Analysis of Privacy Policies with LLMs	Quantifying Website Privacy Posture through Technical and Policy-Based Assessment
Web Applications Headers
Email security
Certificate
Phishing Domains and Squatting Domains
Reputation domain score
DNSSEC
Cookies
Records of Data Processing Activities (DPA)
General requirement for Third—party data transfer (TPD)
Data Protection Management System (PMS)
Data Protection Impact Assessment (PIA)
Data Subject Rights (DSR)
Data Protection by default and design (PDD)
Data Breach Notification (DBN)
Technical and Organizational Measures (TOM)
Codes of Conduct & Certifications (CCC)
Data Protection Contact Information (PCI)

outlines the criteria of our methodology in comparison with selected studies in the same area. Notably, this framework includes technical indicators such as email security and phishing domains, which have not been addressed in earlier research. This integrated approach represents a distinct contribution and innovation within the field.

5. Conclusions

This study introduces a new privacy evaluation framework that, for the first time, integrates and quantifies both technical parameters and privacy policy. This unified and standardized approach enables a comprehensive assessment that was not previously available.

Additionally, our research identified connections between certain privacy policy metrics and the implementation of specific technical features. The relationship between policy and technical measures is not strictly one-to-one; however, technical features can be implemented to address weaknesses in privacy policies and improve overall privacy scores.

Furthermore, the observation regarding the relationship between policy and technical metrics is particularly insightful. It highlights data and evidence that are not accessible through other comparable tools. As we mentioned earlier even though Hospital A gain higher score in Privacy Policy 36/100 instead of Hospital B 32/100, the Final Privacy Score of Hospital B 71/100 is greater that Hospital A 67/100, these results underscore the necessity of a synthesis of privacy policy metrics and technical parameters.

By quantifying various privacy indicators, such as web application headers, email security configurations, DNSSEC deployment, certificate validity, and privacy policy clarity, the framework facilitates objective assessments of websites that may also serve auditing purposes. The case study comparing two private hospitals demonstrated the framework’s practical applicability, yielding comparable results and highlighting areas of strength and weakness. Future research is planned on incorporating lightweight on device LLMs to evaluate the cookie and privacy policies of websites and assigning numerical value to them, as well as the creation of an open-source browser extension that will showcase the detected privacy posture of the visited website in a user friendly manner. These efforts aim to meaningfully advance awareness of online privacy.

At this stage our work has focused on establishing and validating the initial structure of the framework and thus the evaluation has been based on an equal-weighted rubric across the 10 criteria. Our future plans include the definition and testing of different weights for each criterion, which can vary depending on the domain of the website under evaluation. Since weighting schemes are domain-specific and may significantly influence the outcomes, we also plan to perform comprehensive sensitivity analysis. This will allow us to assess the robustness of the results under varying domain-specific conditions.

Overall, this framework offers a scalable and standardized approach for website privacy auditing and serves as a valuable tool for organizations aiming to enhance their data protection posture in compliance with evolving regulatory landscapes.