The Shared Responsibility Gap in Cloud Research Enclaves

Universities evaluating cloud platforms for regulated research typically start with a reasonable assumption: the cloud provider handles security, and the institution handles research. The shared responsibility model promises exactly this. The provider secures the infrastructure. The customer secures everything running on it.

In practice, "everything running on it" includes most of the controls that NIST SP 800-171 actually requires. Access management, audit logging, session isolation, media protection, incident response, and configuration management all remain the customer's responsibility. The provider secures the rack. The institution must still secure the research.

This is not a criticism of cloud platforms. It is a description of the model. The problem is that many institutions adopt cloud-based research environments believing they have purchased compliance, when what they have purchased is infrastructure.

What the Shared Responsibility Model Actually Divides

NIST SP 800-171 defines 110 practices across 14 control families. In a managed cloud deployment, the provider typically covers physical protection (PE) and portions of maintenance (MA) and system integrity (SI). The remaining control families, including the ones that assessors spend the most time on, fall to the institution.

The following matrix shows who owns each layer of the compliance stack in a managed cloud deployment versus a tiCrypt deployment.

NIST 800-171 Responsibility Matrix

Responsibility	Managed Cloud	tiCrypt
Infrastructure
Physical datacenter	Cloud provider	Institution
Hypervisor & compute	Cloud provider	tiCrypt
Operating system	Shared	tiCrypt
Security Controls
Data encryption & key management	Institution	tiCrypt
Identity & authentication	Institution	tiCrypt
Access control	Institution	tiCrypt
Session isolation	Institution	tiCrypt
Audit & monitoring	Institution	tiCrypt
Configuration management	Institution	tiCrypt
Network security controls	Institution	tiCrypt
Media protection & disposal	Institution	tiCrypt
Operations & Governance
Incident response	Institution	Shared
Risk & security assessment	Institution	Shared
System Security Plan (SSP)	Institution	Shared
Personnel security & training	Institution	Institution

Based on NIST SP 800-171's 110 practices across 14 control families. Click any tiCrypt cell for implementation details.

In the managed cloud model, the institution must perform hands-on implementation work for 12 of 14 control families. Physical Protection is the only family the provider fully covers. Maintenance is the only one where the split is roughly even. Everything else requires the institution to design, implement, document, and defend the control during assessment.

In the tiCrypt model, the platform handles 80 of 110 controls architecturally, with 4 more jointly managed. The institution retains responsibility for personnel security policies, awareness training, physical protection of its own data center, and organizational risk assessment. The technical controls that consume the most assessment time and create the most operational burden are enforced by the platform rather than configured by the institution.

Where the Gaps Appear and How tiCrypt Closes Them

The controls that create the most difficulty in cloud deployments are not the ones the provider leaves blank. They are the ones the provider partially covers, creating ambiguity about who owns the implementation. During an assessment, ambiguity becomes a finding.

tiCrypt is an on-premises secure research enclave that addresses these gaps at the architecture level. In the cloud model, controls exist as options the institution must select and maintain. In tiCrypt, controls are enforced by the platform itself. There is no configuration to drift, no security group to misconfigure, and no administrator access path to restrict.

Access Control

Cloud platforms provide IAM services, but IAM is a toolkit, not a policy. The institution must define roles, enforce least privilege, manage the lifecycle of credentials, and ensure that administrators cannot access research data.

In a default cloud configuration, tenant administrators have privileged access paths to the underlying infrastructure, including storage volumes and network traffic. Restricting this requires deliberate, ongoing configuration that the platform does not enforce by default. NIST SP 800-171 practices 3.1.1 and 3.1.2 require that access be limited to authorized users and to the types of transactions and functions they are permitted to execute. A cloud IAM policy that grants broad administrative roles to IT staff may technically satisfy the platform's requirements while violating the control's intent.

The challenge is compounded in university environments. Research teams change composition frequently. Students graduate, postdocs rotate, and collaborators join from other institutions. Each change requires updating access policies across every cloud tenant where that individual had access. In a cloud deployment, each missed update is a potential audit finding.

tiCrypt replaces configurable access policies with cryptographic access control. Every user generates their own RSA-2048 key pair at registration. Authentication uses digital signatures, not passwords. There is no central credential store to compromise. System administrators can manage the platform without ever accessing research data, because they do not possess the decryption keys. This is not a policy decision that could be reversed by a configuration change. It is a consequence of the key architecture.

When a researcher leaves a project, revoking their access means revoking their key. There is no residual access through a cached credential, a lingering IAM role, or a forgotten service account. The cryptographic boundary is absolute.

Audit and Accountability

Cloud platforms generate logs. But NIST SP 800-171 requires more than log generation:

• Practice 3.3.1 requires the institution to create and retain audit records to enable monitoring, analysis, investigation, and reporting
• Practice 3.3.2 requires that actions be traced to individual users
• Practice 3.3.4 requires alerts when audit logging fails

Meeting these requirements in a cloud environment means deploying a SIEM, defining alerting rules, establishing retention policies, protecting logs from tampering, and producing audit evidence in a format that an assessor can validate. The provider's logging console is a data source, not a compliance control. The institution must build the compliance layer on top of it.

This is not a one-time configuration exercise. Audit systems require ongoing maintenance: new event sources must be integrated as the environment changes, alert thresholds must be tuned to reduce false positives without missing real events, and log integrity must be verified continuously. Each of these is an operational commitment that requires dedicated personnel with security expertise.

tiCrypt eliminates this burden with tamper-evident audit logging built into the platform. Every operation is tracked with blockchain hash-chained audit logs and independent authentication. Logs cannot be modified after the fact without breaking the hash chain. There is no separate SIEM to deploy, no log aggregation to configure, and no retention policy to enforce manually.

During an assessment, the evidence is already there. The assessor can verify the hash chain independently. There is no question about whether logs were retained long enough, whether they were protected from tampering, or whether they cover all relevant events. The platform produces the evidence as a byproduct of normal operation.

Session Isolation

This is where the model diverges most sharply from what regulated research requires. Cloud environments use container or VM isolation with shared networking. Cross-tenant visibility is prevented by configuration, not by architecture. NIST SP 800-171 practices 3.13.1 (boundary protection), 3.13.2 (security architecture), and 3.13.4 (preventing unauthorized information transfer via shared resources) all require controls that cloud configurations must engineer project by project.

For institutions managing multiple concurrent regulated projects, each project environment must be separately configured to prevent cross-project data access. A misconfigured security group or storage bucket policy can expose one project's data to another. An overly permissive network ACL can allow traffic between projects that should be completely isolated. The isolation is only as strong as the configuration, and configuration is the customer's responsibility.

This matters because many universities handle data governed by different frameworks simultaneously. A HIPAA project and a CMMC project running in adjacent cloud tenants may have different access policies, different retention requirements, and different incident response obligations. If the boundary between them is a security group rule rather than a cryptographic guarantee, the institution carries the risk of cross-contamination and must demonstrate during assessment that the boundary is enforced.

tiCrypt provides architectural isolation rather than configurational isolation. Each research environment runs in a dedicated encrypted VM using LUKS or BitLocker. Different research groups are isolated from one another by default through the PKI encryption model. Each user and resource is protected by unique public/private key pairs, so cross-project data access is cryptographically impossible without the corresponding private keys.

There is no shared networking, no cross-tenant visibility, and no administrator access path to unencrypted data. Adding a new regulated project does not require configuring new isolation boundaries. For institutions managing CMMC and HIPAA and ITAR projects simultaneously, tiCrypt provides framework-agnostic isolation without per-project configuration work.

Media Protection and Key Management

Cloud providers offer encryption, but the provider typically manages the keys or retains an access path to them. NIST SP 800-171 practice 3.8.6 requires that CUI on digital media be destroyed using approved methods. Practice 3.13.11 requires FIPS-validated cryptography.

In a cloud environment, the institution may not have direct visibility into where data physically resides, how storage is allocated across physical drives, or how decommissioned drives are sanitized. The provider's attestation may cover their process, but the institution cannot independently verify it. For data subject to ITAR or EAR, this lack of visibility into physical data location can be a compliance concern in its own right.

When the cloud provider manages encryption keys, or when the provider's infrastructure retains a technical path to decryption (through privileged administrative access, key escrow, or hardware-level access), the institution cannot make an unqualified claim that only authorized personnel can access the data. Closing this gap within the shared responsibility model requires third-party key management infrastructure, which adds cost and complexity.

tiCrypt takes a fundamentally different approach: encryption keys are generated and held by the data owner, not the infrastructure. Data is encrypted end-to-end with AES-256 at rest, in transit, and during processing. tiCrypt's architecture ensures that even a full compromise of the underlying hardware yields only encrypted data with no path to the keys.

The platform cannot decrypt data it does not hold keys for, and it never holds keys for research data. For data subject to ITAR, EAR, or other export controls where the question of who can access the data has legal consequences, this distinction is material.

Configuration Management

Cloud environments are highly configurable, which is both their strength and their compliance risk. NIST SP 800-171 practice 3.4.1 requires baseline configurations for information systems. Practice 3.4.2 requires that configuration changes be tracked and controlled.

In practice, cloud environments drift. Security group rules accumulate exceptions. IAM policies are modified to unblock a researcher who needs access by Friday. A storage bucket is temporarily made accessible for a data transfer and never locked back down. Each of these changes may be individually reasonable but collectively erode the security posture. Without continuous monitoring and automated enforcement of baseline configurations, drift is not a question of if but when.

The risk is elevated by the complexity of the services themselves. A single cloud platform may offer dozens of storage, networking, and identity services, each with its own configuration surface. A security team must understand the compliance implications of every service in use and monitor configuration across all of them. For university IT teams that are already understaffed (76% of institutions in the EDUCAUSE survey cited limited personnel as a barrier to NIST 800-171 compliance), this is a significant operational burden.

In tiCrypt, there is no configuration surface for controls to drift from. The encryption is always on. The key management is always user-held. The session isolation is always enforced. The audit logging is always hash-chained. These are not settings that an administrator can accidentally change or a researcher can circumvent. They are structural properties of how the platform operates.

A cloud environment may be fully compliant on the day of assessment and non-compliant six months later due to accumulated configuration changes. tiCrypt's compliance posture does not degrade between assessments because the controls are not maintained through configuration.

Incident Response

Cloud providers have their own incident response processes, but they cover provider-side incidents: hardware failures, hypervisor vulnerabilities, data center events. Tenant-side incidents, including unauthorized access to research data, compromised credentials, or data exfiltration, are the institution's responsibility to detect, respond to, and report.

NIST SP 800-171 practice 3.6.1 requires that the institution establish incident response capabilities including preparation, detection, analysis, containment, recovery, and user response. Practice 3.6.2 requires tracking, documenting, and reporting incidents. In a cloud environment, the institution must build these capabilities from the provider's raw event data, which requires both the tooling and the expertise to interpret cloud-specific telemetry.

For universities, incident response is further complicated by reporting obligations. CMMC requires reporting certain incidents to the DoD within 72 hours. HIPAA has its own notification timeline. If the institution lacks the monitoring to detect an incident, the reporting obligation becomes moot, and the compliance failure compounds.

tiCrypt provides built-in detection and forensic evidence: tamper-evident audit trails, real-time telemetry, and hash-chained logs that simplify post-incident investigation and evidence preservation. The institution still establishes response procedures, reporting timelines, and escalation paths, but the platform provides the visibility that cloud environments require the institution to build from scratch.

HPC Workloads

Cloud platforms generally do not support SLURM-based high-performance computing workflows. This is a significant limitation for institutions running computationally intensive regulated research. Genomic analysis, fluid dynamics simulations, AI model training, and other HPC workloads require job scheduling, shared compute resources, and high-bandwidth interconnects that cloud platforms were not designed to provide at the same cost or performance as on-premises clusters.

tiCrypt's split-instance SLURM architecture separates job scheduling from execution. The global scheduler allocates resources across projects without seeing user data or code. Jobs execute inside encrypted, isolated VMs. Researchers submit batch jobs and use computational clusters the same way they always have, but every operation runs inside the enclave boundary.

The same physical hardware serves multiple projects by scheduling jobs across available capacity, improving resource utilization and reducing the total hardware footprint. Cloud and decentralized models generally cannot achieve this, because the project-level isolation required for compliance makes shared HPC job scheduling across projects impractical.

The Full Comparison

Dimension	Managed Cloud	tiCrypt
Control implementation	Customer-configured per environment	Enforced by platform architecture
Administrator access to data	Privileged access paths exist by default	Cryptographically impossible by design
Session isolation	Configuration-dependent	Architectural (PKI + encrypted VMs)
Audit logging	Customer deploys SIEM	Built-in, tamper-evident, hash-chained
Key management	Provider-managed or shared	Data-owner-held, never leaves possession
HPC / SLURM support	Generally unavailable	Native split-instance SLURM integration
Assessment scope	Per-environment or per-tenant	Single environment, reused across projects
Cost model	Consumption-based, variable	Fixed license, unlimited seats
Control drift risk	Moderate to high	Low (controls are structural)
Researcher burden	Moderate (platform familiarity required)	Low (controls abstracted from users)
SSP ownership	Customer-written per environment	Centralized, maintained once, templated
Evidence collection	Manual, per environment	Automatic, centralized, repeatable
Onboarding new projects	Requires environment setup and configuration	Standardized intake process
Boundary enforcement	Configuration-dependent	Enforced through architecture
Governance complexity	Shared governance model with provider	Centralized and institution-controlled
Risk of misconfiguration	High (complexity of services)	Low (reduced configuration surface)

The Governance Burden

Beyond individual controls, cloud-based compliance introduces a governance challenge that is structural to the model. The institution must maintain clear ownership of every control, document how each is implemented within the specific cloud environment, and produce evidence on demand. This requires:

• Specialized expertise. Cloud security is a distinct discipline from traditional IT security. Configuring compliant environments on a cloud platform requires personnel who understand both the compliance framework and the platform's service architecture. These skills are scarce and expensive, and the EDUCAUSE survey confirms that most universities do not have sufficient personnel.

• Per-environment documentation. Each cloud tenant or environment scope requires its own SSP, its own body of evidence, and its own assessment boundary definition. The SSP cannot be generic; it must describe the specific configuration of the specific environment. When an institution runs multiple regulated projects across separate cloud environments, documentation effort scales linearly with the number of projects.

• Continuous compliance operations. Compliance is not a one-time achievement. Controls must be monitored, configurations must be validated, access reviews must be conducted, and evidence must be refreshed. In a cloud environment, this operational burden falls entirely on the institution and must be sustained across every environment for the life of every project.

• Shared governance model. The institution must coordinate with the cloud provider on control responsibilities, understand the provider's changes to the platform, and update its own controls when the provider modifies services. This coordination requires a level of engagement that many university IT organizations are not structured to provide.

Decentralized project-level approaches compound these problems. When individual research groups build their own environments, whether on cloud or on local infrastructure, control implementation varies across projects. Documentation quality is uneven. Researchers assume responsibilities that require security and compliance expertise they do not have. System Security Plans are developed independently by each project, leading to duplication and inconsistency. Audit readiness becomes difficult to sustain, as evidence must be collected and validated across multiple independent environments with different configurations and different owners.

Decentralized compliance efforts consistently show total cost of ownership at 3x or more compared to centralized models, with certification success rates under 50%. The flexibility of the decentralized approach is real, but for a growing portfolio of regulated projects, it does not scale.

What This Means for Assessment

A C3PAO conducting a CMMC Level 2 assessment does not evaluate the cloud provider's controls. The provider's FedRAMP authorization covers the infrastructure. The assessor evaluates the institution's implementation of controls within that infrastructure. Every gap in tenant-side configuration is a finding against the institution.

The assessment process is detailed. Assessors examine the SSP to understand how each of the 110 practices is implemented. They request evidence: screenshots of IAM policies, SIEM alert configurations, access review logs, incident response plans, configuration baselines, media handling procedures. For each control, they verify that the implementation matches the documentation and that the documentation matches what is actually running. In a cloud environment, the institution must produce all of this evidence from its own systems and demonstrate that it governs the cloud configuration end to end.

This creates a specific operational and cost problem. Each cloud environment or tenant scope requires its own assessment. An institution running five regulated projects across five cloud tenants faces five separate assessment cycles, five SSPs, and five sets of audit evidence. Assessment costs of $63,000 to $200,000 per cycle compound quickly across a growing research portfolio. A mid-size R1 university managing ten regulated projects could face $630,000 to $2 million in annual assessment costs alone, before accounting for the personnel and tooling required to maintain compliance between assessments.

In a centralized enclave like tiCrypt, assessment and certification are performed once annually at the environment level and leveraged across every project within it. There is no per-project SSP, no per-project assessment cycle, and no per-project evidence collection. The SSP is maintained centrally and reused. Evidence is produced by the platform itself. Adding a new regulated project to the environment does not trigger a new assessment.

For institutions with a growing portfolio of regulated work, this difference changes the economics of compliance. Instead of multiplying assessment costs by the number of projects, the institution invests once in the enclave and amortizes that investment across its entire regulated research portfolio.

The Strategic Question

The shared responsibility model is not broken. It works as designed. The provider secures the infrastructure. The institution secures the research. The question is whether the institution has the governance, expertise, and operational discipline to implement and maintain 80+ NIST SP 800-171 controls across every cloud tenant, every project, and every assessment cycle, and to sustain that effort year over year as the portfolio grows and the team turns over.

For institutions that have that capacity, cloud platforms are a viable option with strong scalability characteristics and fast initial provisioning.

For institutions where 76% of peers cite limited personnel as a barrier to compliance, where IT governance is decentralized across departments, and where the research portfolio is growing faster than the security team, the cloud model asks the institution to do exactly what it is least equipped to do: implement and maintain complex security controls across a sprawling, project-by-project configuration surface.

tiCrypt collapses the gap by building compliance into the platform architecture rather than dividing it between the institution and a provider. The assessment is performed once, not per tenant. The encryption is data-owner-held, not provider-managed. The isolation is cryptographic, not configurational. The controls are not options to configure. They are properties of the system.

This is not a theoretical distinction. tiCrypt has passed 7+ independent C3PAO assessments across 8+ R1 research institutions, achieving 110/110 on the most recent CMMC Level 2 evaluation. Across those deployments, 1,200+ researchers run 300+ regulated projects within a single assessed boundary per institution. No per-project SSPs. No per-tenant evidence collection. No shared responsibility gap.

The question for every institution evaluating a cloud enclave is whether it is prepared to own the controls the provider does not cover, sustain that ownership across every project and every assessment cycle, and staff it with expertise that 76% of peers report they do not have. Or whether those controls should be properties of the platform itself.