How a Riyadh Fintech Passed NCA Cloud Cybersecurity Controls 3-1-2 and 3-1-3 in Thirty Days: The Shared-Responsibility Matrix Workshop That Closed Twenty-Eight Findings Without Changing the AWS Architecture
A regulated fintech in Riyadh received twenty-eight findings during its National Cybersecurity Authority assessment of Cloud Cybersecurity Controls 3-1-2 and 3-1-3. The findings covered data classification in cloud environments and encryption key management. The assessor noted that while the organization's AWS security controls were technically sound, they were documented only in the cloud provider's service descriptions and configuration screenshots, not in the organization's own policies or control statements. The result: the entity could not demonstrate ownership of its security posture or prove which controls it managed versus which the provider managed.
The organization faced a compliance deadline and a dilemma. Re-architecting the AWS environment would take months and introduce operational risk. Yet the findings were categorical: without a clear NCA cloud controls shared responsibility matrix that mapped each sub-control to specific AWS services, customer-configured settings, and the evidence artifacts proving both, the assessment could not close.
In a two-day workshop, we built that matrix. Thirty days later, all twenty-eight findings were closed without a single change to the underlying cloud architecture.
This case study describes when an organization needs a shared-responsibility approach to NCA Cloud Cybersecurity Controls, the structure of the workshop that produced the matrix, the six AWS service categories it covered, and the compliance-evidence repository format that satisfied the assessor.
When Documentation Gaps Create Compliance Findings
The National Cybersecurity Authority's Cloud Cybersecurity Controls framework establishes requirements for entities using cloud services in the Kingdom. Control 3-1-2 addresses data classification and handling in cloud environments; Control 3-1-3 addresses encryption and cryptographic key management. Both controls include multiple sub-controls that distinguish between the cloud service provider's responsibilities and the customer's responsibilities.
Many Saudi organizations adopt public cloud platforms precisely because the provider operates robust security controls: encryption at rest, network isolation, identity and access management, logging, and key management services. The technical posture is often strong. The compliance gap emerges when the organization cannot answer three questions during an assessment:
- Which specific sub-control does each AWS service satisfy?
- Which settings did the customer configure, and which are provider defaults?
- Where is the evidence artifact that proves the control operates as described?
When an organization's security documentation references AWS whitepapers or service descriptions rather than its own policies, the assessor cannot verify that the entity understands and governs its portion of the shared-responsibility model. The findings reflect a documentation and governance gap, not a technical security gap.
This is the moment when a structured shared-responsibility matrix becomes necessary.
The Two-Day Workshop Structure
The workshop convened the organization's cloud architect, information security officer, compliance officer, and application team leads. The objective was not to redesign the AWS environment but to map it accurately against NCA sub-controls and produce the evidence repository the assessor required.
Day One: Decomposing Sub-Controls and Enumerating Services
We began by decomposing Controls 3-1-2 and 3-1-3 into their constituent sub-controls. For each sub-control, we identified:
- The specific security outcome the NCA requires
- Whether the outcome is achieved by the provider, the customer, or both
- Which AWS service or feature delivers the outcome
- Which configuration setting the customer controls
- What evidence artifact demonstrates the control
The team enumerated every AWS service in use across the organization's production, staging, and development environments. We grouped these into six categories:
Compute and container services — EC2 instances, Lambda functions, and ECS containers that process classified data and require encryption in transit and at rest.
Storage services — S3 buckets, EBS volumes, and RDS databases where data classification labels must be applied and encryption keys must be customer-managed or customer-controlled.
Key management services — AWS KMS configurations, key policies, key rotation schedules, and access logs that prove the organization controls cryptographic material.
Network services — VPC configurations, security groups, and TLS termination points that enforce encryption in transit.
Identity and access services — IAM policies, role assignments, and access logs that demonstrate least-privilege access to encryption keys and classified data stores.
Logging and monitoring services — CloudTrail, CloudWatch, and Config rules that provide the audit trail for key usage, configuration changes, and access events.
For each service, the team documented the current configuration state, identified the responsible party (AWS or customer), and noted where evidence already existed or needed to be generated.
Day Two: Building the Matrix and the Evidence Repository
On the second day, we constructed the shared-responsibility matrix itself. The matrix is a structured document with five columns:
- NCA sub-control reference — The specific requirement from Control 3-1-2 or 3-1-3.
- AWS service or feature — The native service that satisfies the requirement.
- Provider responsibility — What AWS manages by default (for example, physical security of KMS hardware security modules).
- Customer responsibility — What the organization configures and governs (for example, key policies, rotation schedules, and access controls).
- Evidence artifact — The specific document, screenshot, log export, or configuration file that proves the control operates as described.
The matrix made explicit what had been implicit. For instance, one sub-control under 3-1-3 requires that encryption keys for data classified as "Confidential" or higher be managed separately from lower-classification data. The matrix entry showed:
- AWS service: AWS KMS with customer-managed keys
- Provider responsibility: Hardware security module operation, physical security, and cryptographic algorithm implementation
- Customer responsibility: Key policy definition, key rotation schedule, and access control via IAM roles
- Evidence artifact: KMS key policy JSON export, CloudTrail log showing key usage, and the organization's data classification policy mapping classification labels to specific KMS key ARNs
We repeated this process for all twenty-eight findings. By the end of the second day, the matrix contained every sub-control, every relevant AWS service, and every evidence artifact location.
The final step was to create the compliance-evidence repository. This is a structured folder hierarchy, organized by NCA control number, containing:
- Configuration exports (JSON, YAML, or Terraform state files showing current settings)
- Policy documents (the organization's own data classification policy, encryption policy, and key management standard)
- Log samples (CloudTrail entries showing key creation, rotation, and access events)
- Screenshots (AWS Console views annotated to highlight customer-configured settings)
- Attestation statements (brief narratives explaining how each AWS service satisfies the sub-control, signed by the cloud architect and information security officer)
Each evidence artifact was tagged with the corresponding NCA sub-control reference and the matrix row number, creating a clear audit trail from requirement to implementation to proof.
The Six AWS Service Categories and Their Control Mappings
The matrix covered six service categories. Each category addressed specific sub-controls under 3-1-2 and 3-1-3.
Compute and Container Services
EC2 instances and Lambda functions required encryption at rest for attached storage and encryption in transit for API calls. The matrix mapped these to EBS encryption settings (customer-enabled, using customer-managed KMS keys) and TLS enforcement in application code and API Gateway configurations. Evidence artifacts included Terraform configuration files and application deployment manifests.
Storage Services
S3 buckets storing classified data required bucket policies enforcing encryption at rest, object tagging for classification labels, and access logging. The matrix mapped each requirement to specific S3 bucket settings, the organization's tagging standard, and CloudTrail logs showing object access. RDS databases required encryption at rest using customer-managed keys and automated backup encryption, both mapped to RDS instance settings and KMS key policies.
Key Management Services
AWS KMS was central to Controls 3-1-3. The matrix detailed key policies for each customer-managed key, rotation schedules, and IAM policies restricting key usage to specific roles. Evidence artifacts included KMS key metadata exports, rotation configuration screenshots, and CloudTrail logs showing key usage by service and principal.
Network Services
VPC security groups and network ACLs enforced encryption in transit by restricting traffic to HTTPS and TLS-only protocols. The matrix mapped these to security group rules and application load balancer listener configurations. Evidence artifacts included VPC flow logs and security group rule exports.
Identity and Access Services
IAM policies enforced least-privilege access to KMS keys and S3 buckets containing classified data. The matrix mapped each sub-control requiring access control to specific IAM policy statements, role trust relationships, and access logs. Evidence artifacts included IAM policy JSON exports and CloudTrail logs showing access attempts and denials.
Logging and Monitoring Services
CloudTrail and AWS Config provided the audit trail for all configuration changes and key usage events. The matrix mapped sub-controls requiring audit logs to CloudTrail event selectors, Config rules monitoring encryption settings, and log retention policies. Evidence artifacts included CloudTrail log exports and Config rule compliance reports.
Closing the Findings Without Architecture Changes
Thirty days after the workshop, the organization submitted the shared-responsibility matrix and the compliance-evidence repository to the NCA assessor. The assessor reviewed each matrix entry, cross-referenced the evidence artifacts, and verified that the organization's policies and configuration settings satisfied the sub-controls.
All twenty-eight findings were closed. The AWS architecture remained unchanged. The organization had not deployed new services, migrated workloads, or re-engineered its encryption approach. It had simply made explicit what was implicit: the division of responsibility between provider and customer, the configuration choices the customer controlled, and the evidence proving those choices met NCA requirements.
The matrix became a living document. The organization now updates it quarterly, adding new AWS services as they are adopted and refreshing evidence artifacts as configurations change. The compliance-evidence repository is maintained in a version-controlled S3 bucket, with automated exports triggered by AWS Config rule evaluations.
How We Deliver Cloud Security Assessment and Shared-Responsibility Mapping
Cloud environments assessed against NCA controls require a clear understanding of the shared-responsibility model for each service in use. We deliver this through a structured engagement that produces a shared-responsibility matrix, a cloud security assessment report, cloud security policy and baseline configuration standards, and a remediation roadmap.
The engagement typically runs four to eight weeks, depending on the number of cloud services in scope and the maturity of existing documentation. We assess the major public cloud platforms and local cloud service providers, against the NCA controls and the provider's own security model.
The shared-responsibility model is defined for each service, mapping NCA sub-controls to provider responsibilities, customer responsibilities, and the evidence artifacts that prove compliance. Data residency and approvals are addressed before migration, ensuring that the organization's use of cloud services aligns with regulatory expectations from the outset.
For organizations facing NCA Cloud Cybersecurity Controls assessments, the outcome is a compliance posture that reflects the technical security already in place, documented in a format the assessor can verify without ambiguity.
When to Build Your Shared-Responsibility Matrix
If your organization uses public cloud services and faces an NCA Cloud Cybersecurity Controls assessment, a shared-responsibility matrix is not optional. It is the artifact that proves you govern your portion of the security model.
The time to build it is before the assessment, not during the findings-response period. But as this case study demonstrates, even organizations with tight deadlines and multiple findings can close compliance gaps quickly when the technical controls are sound and the documentation structure is clear.
If you are preparing for an NCA cloud assessment, or if you have received findings that question your governance of cloud security controls, a structured workshop and evidence repository can resolve the gap without re-architecting your environment.
Our Cloud & Application Security service is designed for this scenario. We work with your cloud architects and compliance teams to map your existing AWS, Azure, or local cloud configurations to NCA requirements, produce the shared-responsibility matrix and evidence repository, and deliver the policies and standards that close findings and support ongoing compliance.
