Framework Implementation Maturity in Blockchain-Based Third-Party Compliance Assessment

Framework Implementation Maturity in Blockchain-Based Third-Party Compliance Assessment Jemima Owusu-Tweneboah∗ , Amani Altarawneh∗ , Deepti Gupta† , Maria Luisa Figueroa† ∗ Computer Science Department

arXiv:2607.26087v1 [cs.CR] 27 Jul 2026

Tennessee Technological University, United States {jowusutwe42, aaltarwaneh}@tntech.edu † Computer Information Systems Department Texas A&M University Central, United States {d.gupta, maria.figueroa}@tamuct.edu

Abstract—Cybersecurity and privacy frameworks such as NIST SP 800–53, ISO/IEC 27001, GDPR, and HIPAA are widely used to guide organizational security posture and regulatory compliance. In practice, however, framework adoption is often assessed through point-in-time audits, self-attestations, and fragmented evidence reviews, providing limited assurance that controls are consistently implemented, independently validated, and sustained over time, particularly in environments that rely on third-party vendors. These limitations are amplified in multivendor ecosystems, such as healthcare remote patient monitoring (RPM), where compliance obligations span organizational boundaries and assessments are conducted by multiple independent assessors. This paper investigates how permissioned blockchain systems can support framework implementation maturity measurement rather than static compliance verification. We propose a blockchain-based Third-Party Risk Assessment (TPRA) framework that operationalizes assessment workflows, enforces multiparty governance, and preserves longitudinal assessment state using programmable smart contracts. Building on this framework, we introduce a set of evaluation metrics and a qualitative maturity model designed to assess whether compliance controls are verifiably implemented, governed, and sustained across repeated assessment cycles. Using healthcare Remote Patient Monitoring (RPM) as a representative but non-exhaustive case study, we conduct a scenario-driven, demonstrative evaluation to illustrate how maturity metrics can be applied in practice. The evaluation highlights how immutable assessment records, cryptographic evidence anchoring, and governed assessor consensus enable reproducible, auditable, and longitudinal compliance reasoning that is not supported by traditional audit or centralized Governance, Risk, and Compliance (GRC) approaches. Using scenariodriven evaluation, we illustrate how TPRA supports a governed, evidence-grounded, and maturity-oriented approach to thirdparty compliance assessment in regulated multi-organization settings. Index Terms—Critical Information Infrastructure, cybersecurity policy compliance, NIST SP 800-53, Hyperledger Fabric, Distributed Ledger Technology (DLT), Smart Contracts.

I. I NTRODUCTION Third-party vendors play a critical role in the operation of regulated systems [1], [2], particularly in healthcare and other critical information infrastructure (CII) domains. Services such

as cloud-hosted data storage (e.g., AWS/Azure healthcare workloads), analytics platforms, and Internet-of-Health (IoH) device ecosystems (e.g., connected glucose monitors and cardiac telemetry systems) are routinely operated by external providers. Consider a connected health device that transmits regulated patient telemetry to a cloud backend for storage and analytics. Although vendors may claim HIPAA/GDPR alignment during system design, implementation and iterative updates can introduce gaps across third-party components (e.g., misconfigured storage permissions, incomplete audit logging, weak access governance, or inconsistent key-management practices). Without end-to-end governance and independent verification across stakeholders, compliance degrades into a point-in-time artifact rather than an enforceable, auditable system property. Although cybersecurity frameworks such as NIST SP 80053 define extensive control requirements [3]–[6], vendor compliance is still evaluated largely through point-in-time audits, self-attestations, and document-based assessments [2], [7], [8]. Most programs remain question-driven (e.g., questionnaires and attestations), and recent work has explored blockchain to improve auditability, evidence integrity, and accountability [3], [4]. However, existing approaches largely record artifacts or verify isolated attestations [9], offering limited support for measuring framework implementation maturity across repeated assessment cycles in multi-assessor, governed settings. In this paper, maturity is the degree to which control enforcement is consistently evidenced and reproducible across assessment cycles from system execution, rather than narrative reports. Because current assessments are largely point-in-time and report-centric, outcomes are hard to reproduce, compare, or validate longitudinally (from one assessment period to the next over time). We address this gap by reframing thirdparty compliance assessment as a maturity-oriented evaluation problem, supported by a permissioned-ledger protocol that preserves assessment state across cycles. TPRA goes beyond logging compliance artifacts by introducing a ledger-enforced assessment state machine. Evi-

dence is cryptographically bound to an immutable assessment context, independent assessor judgments are recorded and aggregated via a deterministic rule, and outcome finalization is governed by endorsement policies that specify authorized decision-makers. This paper makes the following contributions toward maturity-oriented third-party compliance assessment: We formalize a repeatable maturity-oriented evaluation model for measuring framework implementation across assessment cycles. • We design a ledger-enforced smart-contract protocol that executes assessment actions and preserves state across cycles. • We define a set of evidence-grounded maturity metrics, derived from protocol artifacts, for evaluating governed third-party compliance assessments over time. • We present a multi-organization threat model and provide proof sketches for integrity binding, non-repudiation, and endorsement-gated finalization. • We evaluate the approach in a healthcare RPM case study and discuss generalization to other regulated, multivendor domains.

•

We prioritize maturity-oriented evaluation and governance enforcement over domain-specific optimization. We validate feasibility through end-to-end workflow execution, systemenforced evidence handling, and maturity metrics derived from protocol traces; large-scale deployment benchmarking remains future work. II. R ELATED W ORK Related work spans (i) third-party assessment and maturity practice, (ii) non-blockchain compliance automation and continuous compliance, and (iii) blockchain-based mechanisms for auditability and governance. Across these areas, prior work improves standardization, efficiency, or tamper-evidence, but offers limited support for maturity-oriented evaluation that is reproducible across assessors and sustained across repeated cycles. Table I summarizes representative approaches and contrasts their support for tamper-evident auditability, governed multi-assessor finalization, reproducible outcomes, longitudinal state, and evidence-grounded metrics. a) Third-Party Assessment and Maturity Practice: Thirdparty cyber risk assessment is commonly treated as an organizational process shaped by context and assessor judgment. Slapničar et al. develop a process theory of supplier cyber risk assessment using qualitative analysis and expert surveys, emphasizing practice variability even under standardized frameworks and the resulting challenges for reproducibility across time and assessors [27]. Formal maturity programs such as the Cybersecurity Maturity Model Certification (CMMC) define maturity levels and assessment objectives [28], but outcomes are typically captured as reports or attestations with limited cryptographic binding between evidence, assessor judgments, and reassessments. Enterprise audit modernization motivates integrity and automation: Kong proposes a blockchain-based

internal audit process in which smart contracts automate audit procedures and immutability/timestamping strengthen evidence credibility [19], and Avancha et al. survey blockchainbased vendor management to motivate transparency, audit trails, and automation of contract/credential verification [13]. These works motivate ledger-backed provenance, but do not specify an executable third-party assessment protocol with preserved independent assessor inputs and governed finalization across recurring cycles, which TPRA operationalizes. b) Non-Blockchain Compliance Automation and Continuous Compliance: Non-blockchain approaches reduce cost and subjectivity via automation and continuous compliance. Angermeir et al. define continuous security compliance, summarize challenges through a tertiary study, and propose a roadmap based on control mappings and verification pipelines [11]. Silva et al. operationalize controls for cloud vulnerability management by decomposing CIS/NIST-style recommendations into actionable conditions, tying checks to automated tool execution, and reporting compliance using CVSS-derived measures (e.g., node verification) [12]. These approaches are effective within single administrative boundaries or centralized platforms, where a unified operator can run tools and consolidate outcomes; in third-party settings, standardized questionnaires and templates remain documentcentric and typically rely on trusted intermediaries, limiting tamper-evident provenance and governed multi-party outcome construction. Chung and Caldas highlight similar multistakeholder coordination challenges and propose a conceptual blockchain-based risk-information model with an initial prototype, but focus on risk-event collaboration rather than protocolenforced assessment semantics and longitudinal maturity measurement [20]. c) Blockchain-Based Auditability and Governance: Permissioned blockchains are frequently used to strengthen integrity, accountability, and access control in regulated workflows. Hyperledger Fabric provides authenticated membership, endorsement policies, and a tamper-evident ledger, enabling governance-enforced transaction validity [29]. Representative systems anchor logs or audit artifacts on-chain: LogStamping proposes blockchain-based log auditing with hybrid onchain/off-chain storage, InterPlanetary File System (IPFS) for scalability, and smart-contract validation [9], while Anderson’s AuditChain uses Fabric chaincode to standardize audit-log structure and consolidate audit data across healthcare organizations [21]. Healthcare-oriented systems similarly apply smart contracts to access governance, consent enforcement, and immutable audit logging, including architectures built on Hyperledger Fabric, IPFS (InterPlanetary File System), and FHIR (Fast Healthcare Interoperability Resources), as well as PBAC (Policy-Based Access Control)-based auditing and related provenance mechanisms [14]–[16], [22]–[25], [30], [31]. Cloud-storage auditing targets integrity verification and dispute handling: Shu et al. propose decentralized public auditing and Banerjee et al. (Cumulus) use smart contracts as a dispute mediator for privacy-preserving audits with reduced on-chain overhead via state channels [17], [18]. Finally, platform-level

TABLE I Q UALITATIVE COMPARISON OF RELATED APPROACHES AND TPRA ACROSS FIVE DIMENSIONS . Work Ilori et al. (2022) [2]

Domain Cybersecurity auditing

Core Technology / Procedure TE Audit MA Gov Reprod Long. State EG Metrics Manual audits, regulatory pro– – – – – cesses Aljumaiah et al. (2025) Critical infrastructure NIST CSF mapping, qualitative – – – – – [10] risk analysis – – Angermeir et al. (2024) Continuous Automation roadmap, control – – ⃝ – ⃝ [11] compliance mappings, verification pipelines Silva et al. (2024) [12] Cloud/IaaS vulnerabil- Automated control operational– – ✓ – ✓ ity management, con- ization + tool execution; CVSStinuous compliance based metrics – ⃝ Avancha et al. (2024) IT vendor Blockchain + smart contracts – – – – [13] management (survey/positioning) – – Gupta et al. (2024) [14] Third-party vendor Blockchain + smart contracts; – – – ⃝ ⃝ risk continuous monitoring of controls (case study) Adlam et al. (2020) [15] Healthcare EHR audit- Hyperledger Fabric audit-log ✓ – – – – ing chaincode/prototype – ⃝ Psarra et al. (2024) [16] Healthcare access con- Permissioned Fabric + ML ✓ – – – trol (LSTM) + fuzzy logic; latency eval – Shu et al. (2021) [17] Cloud storage auditing Blockchain-based decentralized ✓ – – – ⃝ public auditing; DAO/SC mechanism – Banerjee et al. (2025) Cloud data audit (pri- Smart contracts + state ✓ – ✓ – ⃝ [18] vacy) channels; UC security proof; Ethereum prototype Islam et al. (2025) [9] Log auditing (large- Hybrid on-/off-chain + IPFS + ✓ – – – – scale systems) smart-contract validation; perf eval – Kong et al. (2025) [19] Enterprise internal au- Blockchain-based audit process ⃝ – – – – dit + smart contracts (automation framing) – – Chung et al. (2022) [20] Healthcare project risk Blockchain-based collaborative ⃝ – ⃝ – – mgmt risk info model + initial prototype Anderson (2018) [21] Healthcare EHR audit Hyperledger Fabric + chain✓ – ✓ – – logs code to standardize/consolidate audit logs (prototype) Azaria et al. (2016) [22] Healthcare Blockchain-based permission ✓ – ✓ – – permissioning management + immutable access log (prototype) Barbaria et al. (2025) Healthcare data ex- Fabric + IPFS + FHIR; smart ✓ – ✓ – – [23] change compliance contracts for consent/policy enforcement (architecture) Ullah et al. (2024) [24] Healthcare EHR audit- Smart contracts + PBAC pol✓ – ✓ – – ing icy verification; immutable audit trail/logs (implementation) Chatziamanetoglou et Security configuration Permissioned blockchain ✓ – ✓ – – al. (2023) [25] management + smart-contract RBAC + lifecycle provenance Androulaki et al. (2019) Fabric governance Endorsement model + state✓ ✓ ✓ – – [26] primitives based endorsement + security analysis/benchmarks TPRA (This work) Third-party Permissioned blockchain as as✓ ✓ ✓ ✓ ✓ compliance sessment protocol Legend: TE Audit = tamper-evident cross-organization auditability; MA Gov = multi-assessor governed finalization; Reprod = reproducible outcome – = Partial or implicit support; – = construction; Long. State = longitudinal assessment state; EG Metrics = evidence-grounded metrics. ✓ = Full support; ⃝ Not supported.

studies formalize why Fabric supports governed multi-party workflows and motivate endorsement-gated validity, including analyses of accountability, endorsement models, and policy performance [26], [32], [33]. However, most prior work treats the ledger as a logging, access-control, or integrity-verification substrate rather than an assessment protocol that encodes

lifecycle semantics, preserves independent assessor judgments, and enforces governed outcome construction across repeated cycles. d) Research Gap and Positioning: Across procedural maturity programs, non-blockchain compliance automation, and blockchain-based audit systems, a common gap remains:

prior work emphasizes verification, artifact integrity, or workflow efficiency, but does not provide a unified mechanism for measuring framework implementation maturity as a reproducible, multi-assessor, longitudinal process. Integrated cybersecurity auditing models argue for unifying compliance, risk management, and governance [2], [8], but remain largely procedural and do not specify enforceable assessment semantics or protocol-level governance, as reflected in Table I. There, a dimension is coded as Full when it is explicitly supported as a primary feature of the architecture, protocol, or evaluation; Partial when it is present only in limited or indirect form; and None when it is absent or not substantively developed. In contrast, TPRA positions a permissioned blockchain as an enforcement substrate for assessment protocols by binding assessor participation, evidence anchoring, endorsement-gated finalization, and longitudinal state transitions into an auditable history suitable for maturity-oriented evaluation. III. S YSTEM C ONTEXT Remote Patient Monitoring (RPM) systems enable continuous collection and analysis of patient physiological data using networked medical devices and cloud-based platforms. Typical deployments integrate IoH sensing devices (e.g., blood pressure monitors, glucose sensors, cardiac monitors), vendoroperated cloud infrastructures for data ingestion and analytics, and clinical dashboards used by healthcare providers for monitoring and decision support. In practice, RPM device data is transmitted to third-party cloud services for storage, preprocessing, and analytics before clinician access, and multiple external vendors (device manufacturers, cloud providers, analytics platforms, and integrators) participate in processing sensitive health information and in implementing security controls [34]–[36]. This creates cross-organization dependencies in which critical controls may be operated outside the healthcare provider’s administrative boundary. a) Third-Party Accountability and Compliance Asymmetry: Despite this distribution of operational responsibility, healthcare providers remain accountable for compliance with regulatory frameworks such as HIPAA and control baselines such as NIST SP 800-53. However, these frameworks specify what controls should exist more than how their ongoing enforcement should be verified across independently operated vendor environments. Consequently, third-party assessment practice remains largely questionnaire- and document-driven, offering limited verifiable visibility into whether controls are sustained over time versus satisfied at assessment time. b) Assessment and Governance Challenges: RPM highlights governance challenges in third-party assessment. Vendors are often evaluated by multiple independent assessors with different scopes or technical specializations, and assessment outcomes may vary due to expert judgment and evidence interpretation even under the same framework [27], [37]. Further, assessments are typically periodic, producing point-in-time snapshots; changes in vendor configurations, operational practices, and threat conditions between cycles

are not systematically captured, limiting reproducibility and longitudinal comparability. c) Why Healthcare RPM Serves as a Stress Test: We use healthcare RPM as a stringent but representative stress test for maturity-oriented third-party assessment because it is regulated, multi-vendor, and operationally dynamic. While our evaluation is instantiated in RPM, the assessment constructs generalize to other regulated multi-vendor settings (e.g., financial services, critical infrastructure, and cloud enterprise systems) where independent validation, governed outcome construction, and cross-cycle comparability are required. IV. T HIRD -PARTY R ISK A SSESSMENT F RAMEWORK A RCHITECTURE AND D ESIGN This section presents TPRA as a permissioned, multiorganization blockchain application implemented on Hyperledger Fabric. Fabric supports execute–order–validate transaction processing, endorsement-policy governance, and channelbased data partitioning across organizations [29]. These primitives match third-party assessment settings where (i) roles are institutionally known (regulator/assessor/vendor), (ii) state changes require multi-party authorization, and (iii) the system must preserve an immutable, reconstructable assessment history across cycles. TPRA operationalizes third-party compliance assessment as a governed protocol executed on a permissioned blockchain, as shown in Figure 1. Assessment actions (creation, evidence anchoring, voting, and finalization) are encoded as chaincode transactions whose effects are constrained by endorsement policies and role-based authorization. We refer to the TPRA workflow (i.e., the chaincode-enforced assessment lifecycle and endorsement-gated governance) as the TPRA protocol. A. System Model and Actors We consider a regulated third-party ecosystem in which compliance outcomes depend on controls implemented within vendor environments. TPRA models three primary organizations (and logical roles): the Regulator (governance authority), which publishes assessment directives and canonical control statements/questions (e.g., HIPAA-aligned requirements mapped to NIST families) and participates in governance decisions that finalize or certify outcomes; Third-Party Assessor(s), which act as independent evaluators that validate evidence, score control implementation, and contribute votes used to construct outcomes; and Vendor(s), which are thirdparty entities (e.g., device manufacturer, cloud provider) that submit compliance responses and register evidence references. TPRA targets environments with multiple assessors (often specialized by control domain), where reconciliation of conflicting judgments and preservation of longitudinal assessment state are first-class requirements [27]. B. Fabric Network, Channel Governance, and MSP-Based Role Enforcement TPRA is deployed as a Fabric network composed of multiple organizations operating endorsing peers and a crashfault-tolerant ordering service. A Fabric channel defines the

Fig. 1. System overview of TPRA on Hyperledger Fabric. A client invokes assessment functions via a backend API and Fabric SDK using MSP-authenticated identities. Chaincode transactions implement the assessment lifecycle (e.g., vendor registration, framework/question initialization, assessment creation, evidence anchoring, assessor voting, governed finalization, etc.). Transactions are endorsed by designated organizations per policy, ordered by an ordering service, validated, and committed, producing an immutable assessment state and verifiable audit artifact returned to the client.

consortium ledger namespace, membership (MSP roots), and application policies [29]. In TPRA, RegulatorOrg and AssessorOrg run endorsing peers to enforce governance separation, while VendorOrgs may run peers for proposal submission and ledger verification. Fabric’s Membership Service Provider (MSP) binds identities to organizations via X.509 certificates. TPRA uses MSP-backed identities to (i) authenticate invokers, (ii) attribute actions to organizations, and (iii) enforce rolebased access control at the chaincode layer. Each organization issues identities via its Certificate Authority (CA); clients sign proposals and endorsers sign responses, enabling non-repudiable attribution of who invoked an action and which organizations approved it. Application roles (Regulator/Assessor/Vendor) are derived deterministically from MSP ID and certificate attributes, and chaincode authorizes invocation via GetMSPID() and invoker identity checks (e.g., vendors cannot finalize outcomes; assessors cannot publish regulator directives) [29]. The ordering service establishes a total order of transactions per channel and disseminates blocks to peers. Stronger adversaries and accountability considerations are handled in the threat model (Section VI). C. Ledger Data Model and Chaincode Workflow TPRA is specified as a set of Fabric chaincode transactions that operationalize the assessment lifecycle. During endorsement, proposals execute against a peer’s current world state to produce a read-set/write-set; only validated write-sets are committed. TPRA stores structured worldstate objects such as: FrameworkDirective (canonical state-

ments/questions, tags, version metadata), Assessment (vendor ID, scope, framework version, status, deadlines), EvidenceRecord (hash, pointer/URI, timestamps, control mapping), AssessorVote (per-assessor score and rationale metadata without sensitive evidence), and AssessmentOutcome (aggregated results and audit pointers). The contract exposes transactions corresponding to key lifecycle stages (representative interface points: registerVendor, createAssessment, registerEvidence, submitAssessment, submitAssessorVote, and completeAssessmentReview [14]). To support reproducibility under Fabric endorsement, TPRA chaincode is deterministic: state transitions and aggregation rules avoid non-deterministic sources and encode policyrelevant parameters in on-chain state [29]. D. Transaction Processing and Endorsement as Enforceable Governance Fabric separates transaction processing into endorsement (simulation), ordering, and validation/commit. A client sends a proposal to the required endorsing peers; each endorser authenticates the invoker, executes chaincode, returns a readset/write-set, and signs the response. After collecting sufficient endorsements, the client submits the transaction to the ordering service for total ordering and block formation. Peers then validate each transaction by (i) checking endorsementpolicy satisfaction, (ii) verifying endorsement signatures, and (iii) performing Multi-Version Concurrency Control (MVCC) validation against read-set versions; valid write-sets update

world state while invalid transactions remain recorded but do not update state. TPRA encodes governance by requiring multi-organization endorsements for state-changing actions, making authorization enforceable rather than procedural. Examples include: Regulator+Assessor endorsements for publishing directives or finalizing outcomes; assessor quorum for recording votes; and (optionally) Vendor+Assessor co-endorsement for evidenceregistration flows requiring co-acknowledgment. Transactionlevel workflow observations are discussed in Section V, and endorsement-based security guarantees are formalized in Section VI.

under weakened assumptions by enabling identification and blame through undeniable evidence. TPRA aligns with this perspective by ensuring governance-relevant actions (publishing directives, finalizing outcomes) are (i) signed, (ii) endorsed by multiple organizations, and (iii) permanently recorded, supporting dispute resolution using ledger evidence. TPRA does not claim that blockchain automatically improves compliance; instead, it specifies a system in which maturity-relevant artifacts—evidence anchors, assessor votes, endorsement satisfaction, and longitudinal state transitions— are cryptographically bound into an auditable history suitable for measuring framework implementation maturity over time.

E. Evidence Handling and Privacy-Preserving Storage

V. F RAMEWORK I MPLEMENTATION M ATURITY M ETRICS AND S CENARIO -D RIVEN E VALUATION

TPRA separates evidence content from evidence accountability. Evidence artifacts (e.g., policy documents, logs, configuration exports, attestations) remain off-chain in vendorcontrolled or mutually agreed secure repositories. On-chain, TPRA records only cryptographic digests (e.g., SHA-256), minimal metadata (type, control mapping, retention tags), content pointers (URI/location reference), and timestamps, enabling later integrity checking and audit reconstruction without storing sensitive contents. The corresponding integrity binding and non-repudiation properties are analyzed in Section VI. Given an EvidenceRecord, an assessor (or regulator) retrieves the artifact off-chain, recomputes its digest, and compares it to the on-chain hash; assessor judgments are thereby bound to immutable evidence anchors rather than ambiguous document exchange. F. Multi-Assessor Voting and Outcome Construction TPRA treats assessor disagreement as a primary design constraint. Each assessor submits a structured AssessorVote referencing (i) assessment ID, (ii) control-family/category, (iii) numeric and/or categorical judgments, and (iv) rationale metadata. Votes are auditable ledger objects. Chaincode computes an AssessmentOutcome from the set of submitted votes using a deterministic aggregation rule (e.g., weighted averaging by domain and agreement/dispersion-derived confidence), making the outcome reproducible from immutable vote state. Finalization (completeAssessmentReview) is endorsementgated (e.g., Regulator+Assessor), ensuring no single party can unilaterally publish an authoritative compliance report [14]. The endorsement-gated finalization guarantee is formalized as Property P3 in Section VI. G. Auditability, Accountability, and Event-Driven Traceability Beyond immutability, TPRA requires accountable assessment actions: it must be possible to reconstruct who invoked what, which organizations endorsed it, and when it became final. Each chaincode transaction emits audit events (e.g., vendor registered, evidence anchored, vote recorded, outcome finalized) to produce a fine-grained trace aligned with the assessment state machine. Formal work on accountability in permissioned blockchains emphasizes that accountability can remain meaningful even

We evaluate whether TPRA supports credible measurement of framework implementation maturity (in the sense of capability/maturity levels applied to governed assessment processes) in third-party compliance settings. The evaluation is scenariodriven and audit-trail-based: we instantiate the TPRA lifecycle and then analyze the resulting protocol-enforced artifacts using maturity-relevant metrics. Table II summarizes metrics M1– M8 as the protocol-derived dimensions used to assess maturity, while Table III defines qualitative maturity levels used to interpret the combined evidence these metrics provide across repeated assessment cycles. The metrics in this section therefore emphasize protocol and governance properties (e.g., traceability, multi-party validation, and longitudinal state) rather than isolated performance indicators. They are not intended to guarantee control correctness or security effectiveness; instead, they assess whether a system provides the structural and procedural foundations required for credible maturity measurement beyond static compliance snapshots. A. Evaluation Methodology This evaluation uses a scenario-driven, metric-based methodology to assess whether TPRA enables maturityoriented reasoning from protocol traces. Rather than relying on deployment-scale performance measurements, we demonstrate how assessment outcomes are generated, governed, and compared over time using the TPRA protocol (Section IV) and then interpreted using metrics M1–M8 (Table II) and maturity levels L0–L4 (Table III). In this paper, L0–L4 primarily serve as descriptive levels for interpreting TPRA traces, while also illustrating how similar evidence-grounded maturity scales may be reused across comparable governed assessment systems. Specifically, we: (i) construct a realistic third-party assessment scenario in a healthcare RPM setting involving a vendor that provides infrastructure or services to a healthcare organization; (ii) instantiate the TPRA lifecycle, including assessment creation, evidence anchoring, independent assessor voting, and endorsement-gated finalization; and (iii) apply Table II to the resulting ledger artifacts and state across assessment cycles to reason about maturity progression. This

TABLE II F RAMEWORK I MPLEMENTATION M ATURITY M ETRICS AND C ORRESPONDING TPRA A RTIFACTS ID M1

Maturity Metric Assessment Workflow Integrity

M2

Operationalized Framework Controls

M3

Identity and Role Enforcement

M4

Evidence Traceability

M5

Multi-Assessor Governance

M6

Longitudinal Trace Persistence

M7

Auditability and Transparency

M8

Structural CrossAssessment Consistency

TPRA Framework Artifact Ledger-enforced assessment lifecycle with explicit state transitions from assessment initialization to governed finalization. Canonical decomposition of cybersecurity frameworks into structured control families, assessment questions, and expected evidence types. Permissioned identity model enforcing role separation among vendors, assessors, and governance authorities. Cryptographic binding of submitted evidence to specific assessment instances and framework versions. Preservation of independent assessor evaluations with governed aggregation and consensus-based finalization rules. Persistent assessment records enabling comparison across repeated evaluation cycles and temporal reasoning about control enforcement. Immutable recording of assessment actions, evidence references, and finalized compliance outcomes. Reuse of canonical assessment structures across vendors and over time without ad hoc redesign or assessorspecific reconciliation.

TABLE III F RAMEWORK I MPLEMENTATION M ATURITY L EVELS (T HESE LEVELS ARE ORDERED AND CUMULATIVE , LIKE STANDARD MATURITY MODELS ) Level Level 0 – Initial

Level 1 – Repeatable

Level 2 – Verifiable

Level 3 – Governed

Level4 – Continuous

Description Compliance activities are ad hoc, documentbased, and assessed independently with limited traceability or reuse. Standardized assessment procedures exist, but evidence validation and assessor coordination remain largely manual. Assessment outcomes are supported by verifiable evidence references and auditable assessment records. Multi-assessor participation is regulated through defined governance rules and structured assessment finalization. Compliance is assessed iteratively over time, with persistent state enabling longitudinal analysis and maturity tracking.

methodology emphasizes feasibility, governance enforceability, and longitudinal reasoning, while deferring production deployment benchmarking to future work. B. Worked Example: Multi-Assessor Vendor Assessment To illustrate TPRA’s support for maturity assessment, we consider a worked example in which a single vendor is assessed across two cycles, denoted T1 and T2 . The vendor participates in a healthcare RPM ecosystem and operates cloud-based data ingestion and analytics services for a healthcare provider.

We consider two assessment cycles for the same vendor and scope. At T1 , an assessor creates an assessment instance specifying scope, evaluation window, and framework-aligned controls; the vendor submits supporting artifacts (e.g., policy documents, configuration exports, operational records) as off-chain evidence that is registered as on-chain evidence references and cryptographically anchored to the assessment instance. Multiple independent assessors evaluate the evidence and submit votes (potentially divergent) based on their domains. TPRA enforces governed finalization: votes and final outcomes are accepted only under role-based authorization and endorsement constraints, and the finalized assessment (including individual assessor inputs and the governed outcome) is persistently recorded on the ledger. At T2 , the same protocol is repeated with updated evidence reflecting operational changes, producing a second finalized assessment under identical governance constraints. Because TPRA preserves assessment state across cycles, the protocol enables explicit T1 –T2 comparison (evidence completeness, assessor dispersion, governance enforcement, and outcome evolution) to reason about whether controls were sustained, improved, or degraded over time. Interpreted through Table III, T1 typically aligns with Repeatable (L1) or early Verifiable (L2), depending on evidence traceability and auditability. At T2 , improved evidence-tocontrol linkage and reduced ambiguity can strengthen assessor convergence and longitudinal comparison, reflecting progression toward Verifiable (L2) and, when governed reconciliation is consistently enforced, Governed (L3). The key differentiator is that this progression is derived from protocol traces (anchored evidence, recorded votes, and endorsement-gated finalization) rather than static reports. Applying Table II to the two-cycle trace highlights maturityrelevant properties: workflow integrity (M1), evidence traceability (M4), preservation of independent assessor inputs with governed reconciliation (M5), and longitudinal persistence enabling cross-cycle comparison (M6). In traditional point-intime audits, prior assessments are typically archived as static reports without structured linkage, limiting their utility for repeatable longitudinal reasoning. C. Qualitative Scalability Considerations Although this work does not present an empirical performance evaluation, we qualitatively assess whether the framework can scale to realistic third-party compliance settings. The assessment workflow scales primarily with the number of vendors and assessment cycles rather than with highfrequency transaction volume: each assessment instance follows a bounded lifecycle (create, evidence registration, vote submission, finalization). Consequently, ledger interactions grow approximately linearly with assessment events, aligning with periodic reassessment environments typical of compliance programs. Storage growth is moderated by design: evidence content remains off-chain while cryptographic anchors and metadata are recorded on-chain. This enables long-term audit reconstruction

and maturity tracking without storing sensitive artifacts in the ledger state. Permissioned operation with configurable endorsement policies further distributes validation responsibility across organizations while preserving explicit governance constraints. VI. T HREAT M ODEL AND S ECURITY A NALYSIS This section defines the TPRA threat model and argues how the protocol supports integrity, accountability, and governance requirements for multi-organization third-party assessments. Because we evaluate a prototype-level implementation, we focus on protocol-level guarantees, tamper-evident evidence binding, non-repudiation of recorded actions, and endorsement-gated finalization, rather than operational hardening (e.g., sustained DoS resilience). A. System Model and Notation We develop TPRA as a permissioned-ledger protocol that executes assessments over repeated cycles. An assessment instance for vendor vid with scope scope in cycle i is denoted Ai . Evidence artifacts E are stored off-chain; TPRA records an on-chain anchor h ← H(bytes(E)), where H is a collisionresistant hash function, and binds h to Ai . Protocol actions are submitted as signed transactions (m, σ), where m is the transaction payload (e.g., action type, parameters, and references to Ai ) and σ is a digital signature under an authenticated identity. Critical state transitions (e.g., finalization) are commit-valid only if endorsements satisfy the endorsement policy π (e.g., Regulator+Assessor). The ledger L provides an append-only history, and the world state S stores the current assessment state and associated artifacts. B. Threat Model a) Context and motivation: Third-party compliance workflows often rely on questionnaires and distributed evidence exchange (e.g., email, shared drives, and disparate portals), creating recurring risks: stale approvals as controls degrade over time, fragmented audit trails that prevent reliable reconstruction, and weakly validated self-attestations. TPRA targets these risks by binding evidence and decisions to governed, auditable protocol traces. We assume a regulated multi-organization setting in which participants are known and authenticated (permissioned membership), but may act adversarially or strategically. b) Adversary classes: We consider four adversary classes. A malicious vendor (AV ) may submit incomplete or misleading evidence, attempt to alter, withdraw, or substitute evidence after submission, or game assessment scope boundaries, thereby undermining the integrity and completeness of the assurance record. A malicious assessor (AA ) may submit biased votes or rationales, selectively interpret evidence, attempt repudiation of prior actions, or withhold participation to delay finalization, threatening decision integrity and, through delay or non-participation, system availability. A colluding coalition (AC ) may coordinate to influence outcomes (e.g., coordinated voting), but is bounded by endorsement and

quorum thresholds, so its primary effect is on the integrity of aggregated decisions. Finally, an off-chain attacker (AO ) targets evidence storage to delete, replace, rollback, or deny access to evidence objects without controlling on-chain identities, directly threatening evidence integrity and availability. c) Attack Surfaces: We do not treat Fabric consensus safety or ledger immutability as primary attack vectors; instead, we focus on practical, in-scope surfaces: chaincode workflow correctness, client/API misuse, endorsement and identity configuration, and off-chain evidence integrity and availability. Sustained DoS is an operational concern and is not evaluated here. Concretely, the primary attack surfaces include the client-to-ledger submission interfaces, where adversarial inputs or API misuse may target validation logic and workflow preconditions; the chaincode state machine, where missing guards or implementation errors could enable unintended transitions (e.g., premature finalization); and the endorsement/ACL configuration, where mis-scoped or overly permissive policies can weaken multi-party authorization. We also consider identity and key management risks, such as compromised keys or mis-issued certificates enabling validly signed malicious actions, as well as off-chain evidence repositories, which may be targeted for deletion, replacement, rollback, or denial of access. Finally, we include evidence reference binding attacks (e.g., Uniform Resource Identifier (URI) swapping or stale references), mitigated by binding anchors to Ai and recording minimal metadata, and governance/finalization operations where an adversary attempts to bypass role checks or endorsement-gated finalization. C. Assumptions, Scope, and Security Objectives a) Assumptions: Our analysis relies on standard cryptographic and platform assumptions: A1 (Hash security): H(·) is collision resistant; A2 (Signature security): the signature scheme is EUF-CMA secure; and A3 (Endorsement correctness): a transaction is committed only if endorsements satisfy π and all signatures verify. We further assume the permissioned platform correctly enforces membership, endorsement validation, and append-only history. b) Scope and out-of-scope: Physical-device attacks and side channels are out of scope. TPRA does not determine the factual truthfulness of evidence contents; rather, it provides tamper-evidence, attribution, and auditability for what was submitted and how decisions were reached. Availability is treated as an operational concern: multi-organization replication supports access to history, while sustained DoS is not evaluated. c) Security objectives and mechanisms: TPRA targets protocol-level properties required for credible third-party assessment under governance. O1–O3 (Confidentiality, integrity, traceability): evidence contents remain off-chain under repository/IAM controls, while the ledger stores anchors and minimal metadata and chaincode constrains lifecycle transitions, yielding tamper-evident assessment state and evidence provenance. O4 (Accountability/non-repudiation): all actions are identity-bound signed transactions recorded on an

append-only ledger. O5 (Governed finalization): endorsement/quorum policies enforce multi-party authorization for critical actions (e.g., publishing directives and finalizing outcomes), preventing unilateral commits. O6 (Availability, operational): multi-organization replication improves resilience and access to history, but sustained DoS is not evaluated. D. Formal Security Properties and Proof Sketches We provide compact, game-based sketches for three core protocol properties. a) P1: Evidence binding (tamper-evident anchoring): TPRA provides evidence binding if, after an anchor h is committed for an assessment instance A, no adversary can later present a different evidence object as the one anchored by h without detection. Game GBind (Evidence Substitution). The adversary selects an assessment identifier A and submits evidence E. The protocol computes h ← H(bytes(E)) and commits (A, h). The adversary wins if it outputs E ′ ̸= E such that H(bytes(E ′ )) = h. Proof sketch. If the adversary wins GBind , then it has produced E ′ ̸= E such that H(bytes(E ′ )) = H(bytes(E)), which constitutes a hash collision (and more specifically a second-preimage) for H(·). Under Assumption A1, the adversary’s success probability is negligible. b) P2: Non-repudiation of assessment actions: TPRA provides non-repudiation if committed actions cannot be falsely attributed to an honest participant who did not authorize them, and an authorizing participant cannot later deny having signed the action. Game GNR (Action Forgery). The adversary outputs a committed record (m, σ, pk) such that Verifypk (m, σ) = 1 for an honest public key pk, and m was not signed by the corresponding participant. Proof sketch. Winning GNR yields a valid signature on a message not signed by the honest key owner, which contradicts EUF-CMA security (A2); thus the adversary’s success probability is negligible. c) P3: Governed finalization (endorsement-gated outcomes): TPRA provides governed finalization if a final outcome cannot be committed unless the endorsement policy π is satisfied. Game GGov (Policy Bypass). The adversary controls a set of identities whose endorsements do not satisfy π (i.e., it lacks the required endorsing organizations) and wins if it causes a FinalizeOutcome transaction to be committed without the endorsements required by π. Proof sketch. Under A3, a transaction is committed only if the collected endorsements satisfy π and all signatures verify; hence any successful bypass would require either (i) violating endorsement-policy enforcement (breaking A3) or (ii) forging endorsements via signature forgery (contradicting A2). Therefore, the adversary’s success probability is negligible. E. Adversarial Considerations and Limitations TPRA strengthens integrity, accountability, and governed outcome construction, but it does not eliminate all adversarial

risks. Collusion can still influence outcomes if governance thresholds are misconfigured or if sufficient endorsers collude. TPRA also cannot independently verify the factual correctness of off-chain evidence; it provides tamper-evidence, attribution, and auditability for what was submitted and how it was decided. Privacy depends on secure off-chain repositories and access controls, which are assumed but not evaluated here. These limitations motivate future work on stronger collusion resistance, privacy-preserving evidence validation (e.g., selective disclosure), and formal verification of chaincode workflow correctness. VII. D ISCUSSION AND F UTURE W ORK This section summarizes the evaluation implications of TPRA, states scope limitations of our study design, and outlines high-impact next steps. a) Comparative Discussion: Traditional third-party audits are largely point-in-time: evidence is summarized in static reports and prior assessments are not structurally linked to future evaluations. Centralized GRC platforms improve workflow, but typically concentrate interpretation and outcome construction within a single authority, limiting multi-party governance and independently constructed outcomes across organizational boundaries. TPRA reframes assessment as a system property by enforcing assessment semantics through chaincode, requiring endorsement-gated finalization, and preserving assessment state across cycles. The contribution is not new controls or scoring criteria, but a protocol substrate that produces protocol-enforced artifacts (lifecycle state, evidence anchors, assessor inputs, and governed finalization) from which maturity can be inferred, reproduced, and compared longitudinally. The proposed metrics and maturity levels provide a compact basis for comparing third-party compliance systems on governance enforceability, reproducibility, and cross-cycle traceability. b) Future Work: Next steps include applying the methodology to additional regulated domains. In companion work, TPRA-Trust, we will extend TPRA with a protocol-derived trust model for assessor disagreement. The model will trustweight assessor influence during outcome construction, while remaining bounded by quorum/endorsement and appeal constraints. It will also derive longitudinal trust-stability signals across repeated assessment cycles as an additional maturity indicator. Trust values will be computed from ledger-observable behavior (e.g., participation reliability, consistency with prior validated outcomes, and dispute/appeal history). These values will be stored as auditable state reproducible from audit trails. We defer full trust-model definition, parameterization, and robustness analysis (including collusion and strategic behavior) to the TPRA-Trust paper. VIII. C ONCLUSION This paper introduced a maturity-oriented evaluation approach for blockchain-based third-party compliance assessment systems. Rather than treating compliance as a point-intime outcome, we frame third-party assessment as a longitudinal measurement problem that requires verifiable evidence

handling, governed validation, and persistent assessment state across organizational boundaries. We defined framework implementation maturity metrics and a qualitative maturity model grounded in protocol-enforced artifacts (anchored evidence references, preserved assessor inputs, endorsement-gated finalization, and immutable audit traces). Using TPRA as an instantiation in a healthcare remote patient monitoring setting, we demonstrated how these constructs support reproducible and auditable reasoning across assessment cycles. This work does not argue that blockchain universally improves compliance; it identifies when a permissioned ledger is most valuable, when outcomes must be independently validated, tamper-evident, and governed across multiple organizations over time. The proposed metrics and maturity model are domain-agnostic and provide a foundation for designing and comparing third-party compliance systems using maturityoriented criteria. R EFERENCES [1] Z. Gan, “Large language models empowering compliance checks and report generation in auditing,” World Journal of Information Technology, vol. 2024, p. 35, 2024. [2] O. Ilori, C. I. Lawal, S. C. Friday, N. J. Isibor, and E. C. Chukwuma-Eke, “Cybersecurity auditing in the digital age: A review of methodologies and regulatory implications,” Journal of Frontiers in Multidisciplinary Research, vol. 3, no. 1, pp. 174–187, 2022. [3] E. Ni, X. Tang, X. Zhou, D. Lee, A. Elhussein, E. Knight, G. Gürsoy, and M. Gerstein, “Recent advances and future prospects for blockchain in biomedicine,” Cell Reports Methods, 2025. [4] J. Andrew, D. P. Isravel, K. M. Sagayam, B. Bhushan, Y. Sei, and J. Eunice, “Blockchain for healthcare systems: Architecture, security challenges, trends and future directions,” Journal of Network and Computer Applications, vol. 215, p. 103633, 2023. [5] M. Syafrizal, S. R. Selamat, and N. A. Zakaria, “Analysis of cybersecurity standard and framework components,” International Journal of Communication Networks and Information Security, vol. 12, no. 3, pp. 417–432, 2020. [6] W. Wang, S. M. Sadjadi, and N. Rishe, “A survey of major cybersecurity compliance frameworks,” in 2024 IEEE 10th Conference on Big Data Security on Cloud (BigDataSecurity). IEEE, 2024, pp. 23–34. [7] S. Hassani, M. Sabetzadeh, D. Amyot, and J. Liao, “Rethinking legal compliance automation: Opportunities with large language models,” in 2024 IEEE 32nd International Requirements Engineering Conference (RE). IEEE, 2024, pp. 432–440. [8] R. Sabillon, “The cybersecurity audit model (CSAM),” in Research Anthology on Business Aspects of Cybersecurity. IGI Global, 2022, pp. 77–139. [9] M. S. Islam and M. S. Rahman, “LogStamping: A blockchainbased log auditing approach for large-scale systems,” arXiv preprint arXiv:2505.17236, 2025. [10] O. Aljumaiah, W. Jiang, S. R. Addula, and M. A. Almaiah, “Analyzing cybersecurity risks and threats in IT infrastructure based on NIST framework,” J. Cyber Secur. Risk Audit, vol. 2025, no. 2, pp. 12–26, 2025. [11] F. Angermeir, J. Fischbach, F. Moyón, and D. Mendez, “Towards automated continuous security compliance,” in Proceedings of the 18th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement, 2024, pp. 440–446. [12] R. Silva, A. Brito, and J. P. de Lima Filho, “Automation of security controls for continuous compliance in vulnerability management,” in Proceedings of the 13th Latin-American Symposium on Dependable and Secure Computing, 2024, pp. 1–10. [13] S. Avancha and E. O. Goel, “Blockchain-based vendor management in IT: Challenges and solutions,” Scientific Journal of Metaverse and Blockchain Technology, vol. 2, no. 2, pp. 68–71, 2024.

[14] D. Gupta, L. Elluri, A. Jain, S. S. Moni, and O. Aslan, “Blockchainenhanced framework for secure third-party vendor risk management and vigilant security controls,” in 2024 IEEE International Conference on Big Data (BigData). IEEE, 2024, pp. 5577–5584. [15] R. Adlam and B. Haskins, “A permissioned blockchain approach to electronic health record audit logs,” in Proceedings of the 2nd International Conference on Intelligent and Innovative Computing Applications, 2020, pp. 1–7. [16] E. Psarra, D. Apostolou, Y. Verginadis, I. Patiniotakis, and G. Mentzas, “Permissioned blockchain network for proactive access control to electronic health records,” BMC Medical Informatics and Decision Making, vol. 24, no. 1, p. 303, 2024. [17] J. Shu, X. Zou, X. Jia, W. Zhang, and R. Xie, “Blockchain-based decentralized public auditing for cloud storage,” IEEE Transactions on Cloud Computing, vol. 10, no. 4, pp. 2366–2380, 2021. [18] P. Banerjee, N. Nikam, S. Mazumdar, and S. Ruj, “Cumulus: Blockchain-enabled privacy-preserving data audit in cloud,” Distributed Ledger Technologies: Research and Practice, vol. 4, no. 3, pp. 1–28, 2025. [19] X. Kong, “Research on enterprise internal audit based on blockchain technology,” in Proceedings of the 10th International Conference on Cyber Security and Information Engineering (ICCSIE ’25). ACM, 2025, pp. 337–343. [20] I. B. Chung and C. Caldas, “Applicability of blockchain-based implementation for risk management in healthcare projects,” Blockchain in Healthcare Today, vol. 5, p. 191, 2022. [21] J. Anderson, “Securing, standardizing, and simplifying electronic health record audit logs through permissioned blockchain technology,” Dartmouth College, Tech. Rep. TR2018-854, 2018. [22] A. Azaria, A. Ekblaw, T. Vieira, and A. Lippman, “MedRec: Using blockchain for medical data access and permission management,” in 2016 2nd International Conference on Open and Big Data (OBD). IEEE, 2016, pp. 25–30. [23] S. Barbaria, A. Jemai, H. İ. Ceylan, R. I. Muntean, I. Dergaa, and H. Boussi Rahmouni, “Advancing compliance with HIPAA and GDPR in healthcare: A blockchain-based strategy for secure data exchange in clinical research involving private health information,” Healthcare, vol. 13, no. 20, p. 2594, 2025. [24] F. Ullah, J. He, N. Zhu, A. Wajahat, A. Nazir, S. Qureshi, M. S. Pathan, and S. Dev, “Blockchain-enabled EHR access auditing: Enhancing healthcare data security,” Heliyon, vol. 10, no. 16, 2024. [25] D. Chatziamanetoglou and K. Rantos, “Blockchain-based security configuration management for ICT systems,” Electronics, vol. 12, no. 8, p. 1879, 2023. [26] E. Androulaki, A. De Caro, M. Neugschwandtner, and A. Sorniotti, “Endorsement in Hyperledger Fabric,” in 2019 IEEE International Conference on Blockchain (Blockchain). IEEE, 2019, pp. 510–519. [27] S. Slapnicar, T. Vidmar, E. Tsen et al., “Process theory of supplier cyber risk assessment,” Australasian Journal of Information Systems, vol. 29, 2025. [28] H. Strohmier, G. Stoker, M. Vanajakumari, U. Clark, J. Cummings, and M. Modaresnezhad, “Cybersecurity maturity model certification initial impact on the defense industrial base,” Journal of Information Systems Applied Research, vol. 15, no. 2, pp. 17–29, 2022. [29] E. Androulaki, A. Barger, V. Bortnikov, C. Cachin, K. Christidis, A. De Caro, D. Enyeart, C. Ferris, G. Laventman, Y. Manevich et al., “Hyperledger fabric: A distributed operating system for permissioned blockchains,” in Proceedings of the Thirteenth EuroSys Conference, 2018, pp. 1–15. [30] A. Tawfik et al., “ACHealthChain: A blockchain-based access control framework for healthcare,” Scientific Reports, 2025. [31] K. Shuaib, J. Abdella, F. Sallabi, and M. A. Serhani, “Secure decentralized electronic health records sharing system based on blockchains,” Journal of King Saud University - Computer and Information Sciences, vol. 34, no. 8, pp. 5045–5058, 2022. [32] M. Graf, R. Küsters, and D. Rausch, “Accountability in a permissioned blockchain: Formal analysis of Hyperledger Fabric,” in 2020 IEEE European Symposium on Security and Privacy (EuroS&P). IEEE, 2020, pp. 236–255. [33] X. Piao, H. Ding, and H. Song, “Performance analysis of endorsement in Hyperledger Fabric concerning endorsement policies,” Electronics, vol. 12, no. 20, p. 4322, 2023.

[34] K. Abouelmehdi, A. Beni-Hessane, and H. Khaloufi, “Big healthcare data: Preserving security and privacy,” Journal of Big Data, vol. 5, no. 1, pp. 1–18, 2018. [35] J. L. Fernández-Alemán, I. C. Señor, P. Á. O. Lozoya, and A. Toval, “Security and privacy in electronic health records: A systematic literature review,” Journal of Biomedical Informatics, vol. 46, no. 3, pp. 541–562, 2013. [36] M. Reisman, “EHRs: The challenge of making electronic data usable and interoperable,” Pharmacy and Therapeutics, vol. 42, no. 9, p. 572, 2017. [37] O. F. Keskin, K. M. Caramancion, I. Tatar, O. Raza, and U. Tatar, “Cyber third-party risk management: A comparison of non-intrusive risk scoring reports,” Electronics, vol. 10, no. 10, p. 1168, 2021.