Control area

Application security: who owns it on each service model

The security of the code that runs on the service. Your code is yours; the provider's application is the provider's.

The split by service model

Service model	Owner	Why, and the clause
Infrastructure as a service	yours	The code you deploy is yours to build and test securely; the provider has no view of it. ISO/IEC 27017 14.2.1
Platform as a service	yours	The code you deploy is yours to build and test securely; the provider has no view of it. ISO/IEC 27017 14.2.1
Software as a service	the provider's	The application is the provider's to build and test; your side is the integrations and extensions you add to it. ISO/IEC 27017 14.2.1
Serverless functions and event services	yours	The code you deploy is yours to build and test securely; the provider has no view of it. ISO/IEC 27017 14.2.1
Hosted AI models and AI platforms	shared	The provider secures the model endpoint; the application around it, how you handle what goes in and what comes back, is yours. ISO/IEC 27017 14.2.1

The clauses each framework attaches

5 quoted

Framework	Clause
Cloud Controls Matrix v4.0.1	CCM-AIS-04 Secure Application Design and Development
ISO/IEC 27017:2015	ISO/IEC 27017 14.2.1 Secure development policy
SOC 2 Trust Services Criteria	SOC 2 CC8.1 Change management processes are in place
CMMC 2.0	CMMC SC.L2-3.13.2 Security Engineering
C5 cloud criteria catalogue	C5-DEV-01 Policies for the development/procurement of information systems

CCM-AIS-04 Secure Application Design and Development

Build applications through a secure development lifecycle so the organisation's security requirements are applied at design, build, deployment and operation.

What an assessor asks to see:

The documented secure development lifecycle with security activities at each stage
Design review or threat model records for recent applications
Evidence of security requirements being carried into build and deployment
Records showing the lifecycle applied to a real project end to end

Where it usually falls short:

Security activity concentrated at the end of the lifecycle only
Threat modelling done for flagship projects and skipped elsewhere
Operational stage excluded, so security requirements stop at go-live

Source: Cloud Controls Matrix v4.0.1

ISO/IEC 27017 14.2.1 Secure development policy

Where the customer develops applications on a cloud service, its secure development policy should address the cloud environment, including the provider's development tools and interfaces and the security of code and data in shared development resources. The provider should give customers information about the secure development practices and the interfaces it makes available.

What an assessor asks to see:

Customer secure development policy with a cloud section
Provider documentation of development interfaces and practices
Review of cloud-hosted development environments against the policy

Where it usually falls short:

Production credentials used in a cloud development environment
Customer developers using provider tooling with no security guidance

Source: ISO/IEC 27017:2015

SOC 2 CC8.1 Change management processes are in place

Authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives

What an assessor asks to see:

The change management process covering infrastructure, data, software and procedures, including the emergency change route
Change records for the period showing design, development or acquisition, configuration, documentation, testing, approval and implementation
Evidence of segregation between those who develop, approve and implement changes
Testing evidence per change proportionate to its risk, including security testing where relevant
Evidence of rollback capability and of post implementation verification

Where it usually falls short:

Emergency changes used routinely, with retrospective approval that is never withheld
Approval and implementation performed by the same person, so the approval is not independent
Automated deployment pipelines outside the documented process, so most changes are untested against it
Infrastructure and configuration change treated as out of scope because the process was written for application code

Source: SOC 2 Trust Services Criteria

CMMC SC.L2-3.13.2 Security Engineering Level 2

Apply architectural design, software development techniques and systems engineering principles that promote effective information security.

What an assessor asks to see:

Documented security architecture and design principles
Secure development standards applied to in house software
Evidence principles are applied in design reviews

Where it usually falls short:

Principles documented but absent from actual design decisions
Secure development standards not applied to acquired or outsourced code
No design review step in the development process

Source: CMMC 2.0

C5-DEV-01 Policies for the development/procurement of information systems

Issue secure development policies covering the whole service lifecycle and grounded in recognised standards, addressing security in requirements, design, implementation, testing and verification, in software deployment including continuous delivery, and in reacting to faults and vulnerabilities during operation.

What an assessor asks to see:

Secure development policy naming the standard or method it is built on
Lifecycle description running from requirements through to operational vulnerability handling
Deployment security instruction covering the continuous delivery route
Proof that the policy was issued to internal developers and contracted development staff

Where it usually falls short:

Policy stops at coding conventions and is silent on deployment and operation
Delivery pipelines run under no documented security requirement at all
No recognised standard underpins the policy, so its completeness cannot be judged

Source: C5 cloud criteria catalogue