A.5.23 Cloud services security: requirements and evidence

What A.5.23 asks for cloud services in an ISO 27001 audit

A.5.23 asks the organization to set up processes for acquiring, using, managing and exiting cloud services, and to run those processes in line with its own information security requirements. In an audit, the assessor will look for a documented, followed process that covers the whole life of each cloud service, and for clear records of which security duties sit with the organization and which sit with the provider. The organization owns this control even when a provider runs the platform, so the shared responsibility split must be written down for each service, not assumed from the provider's marketing material. A.5.23 is one of the 11 controls that are new in the 2022 revision of Annex A, and it sits beside the supplier group, A.5.19 to A.5.22, which covers supplier risk assessment, contract terms, supply chain and ongoing service monitoring. Where those controls govern suppliers in general, A.5.23 focuses on cloud, where accounts are often created by individual teams, data moves across borders and the provider's controls are only partly visible. Two cloud-specific sources help here: ISO/IEC 27002:2022 gives implementation guidance for the control, and ISO/IEC 27017:2026 adds cloud-specific guidance and additional controls for both cloud service customers and providers. Confirm with your certification body which edition it expects you to reference.

Three gaps cause most of the difficulty. The first is unknown cloud accounts: subscriptions opened on corporate cards or by developers never reach the asset inventory, so no one has assessed them. The second is unclear provider duties: teams assume the provider handles backups, logging or key management when the contract says otherwise. The third is the missing exit plan: without a tested route for moving data and workloads out, the exit stage of the control exists only on paper. Start by listing every cloud service in use, naming an owner for each, and checking the contract for the responsibility split and the data return terms.

Which cloud services and teams fall inside A.5.23

Scoping decides how much of the cloud estate A.5.23 must cover and who answers for each part. The cards below separate the service models, the services teams buy without central approval, and the systems that administer everything else. Each one connects back to the cloud inventory, which is where A.5.9 and A.5.23 meet.

IaaS: where the organization holds the most responsibility

Infrastructure as a service gives the organization virtual machines, storage and networks that it configures itself. The provider secures the physical facility and hypervisor, but the operating systems, patching, network rules and images stay with the organization. Scope these accounts and subscriptions in full, because each one is a place where configuration drifts. Ask who builds the base images, who can create new accounts and where the logs for each account are sent.

PaaS: shared responsibility for the platform layer

Platform services such as managed databases, container orchestration and serverless runtimes run much of the stack for the organization. Responsibilities split at the platform boundary: the provider patches the runtime, while the organization still owns application code, data classification, identity settings and encryption choices. Record that split per service, not per provider, because two managed databases from the same vendor can carry different customer duties.

SaaS: contracts and configuration over controls

Software as a service removes most infrastructure work but leaves configuration, user access, data sharing settings and exit planning with the organization. The provider's security documentation and contract terms define what it does, so the organization must confirm them before relying on them. Each SaaS product needs an owner, a list of administrators and a documented way to retrieve data at the end of the contract.

Shadow SaaS bought by teams

Business teams often sign up for tools with a corporate card or a free trial, and these services can hold customer data without any review. A.5.23 expects processes for acquiring cloud services, so unapproved purchases fall outside the process by definition. Look for them through expense records, single sign-on logs, OAuth grants and browser or network telemetry, then decide whether each one is approved, replaced or removed.

Services that hold information versus services that touch it

A service that stores or processes in-scope information needs full assessment of its controls, contract terms and exit route. A service that only touches it, such as a chat tool that receives a link, a monitoring agent that reads logs or a single sign-on provider that checks credentials, may need lighter review but still needs a recorded decision. Document the reason for each classification, because assessors will ask why a service was excluded.

Multi-cloud and cloud management consoles

Organizations with several providers must track each tenant, and the management consoles that span them can grant control over every account at once. Treat consoles, infrastructure-as-code pipelines and cross-account roles as cloud services in their own right, with privileged access reviewed separately. Confirm which provider holds which workload, how identity federates between providers and who is named as the owner of each tenant.

Linking the cloud inventory to A.5.9

A.5.9 requires an inventory of information and associated assets with owners, and cloud services belong in it. Record each service with its model (IaaS, PaaS or SaaS), the information it holds, its business owner, its account or tenant identifier and its exit contact. Reconcile the inventory against billing and identity data each quarter, because auditors sample cloud spend and single sign-on records to test whether the inventory is complete.

How an assessor tests A.5.23

This table walks through the test steps an assessor typically runs against A.5.23, the evidence each step asks for, and the findings that most often come up. Read it as a preparation list: each row is something the organization should be able to show before the audit starts.

Test step	What the assessor checks	Evidence requested	Common findings
Review the documented cloud process	Whether a process covers acquiring, using, managing and exiting cloud services, and whether it reflects the organization's information security requirements for cloud	Cloud services procedure, approval criteria, security requirements for cloud use, document version and approval record	Procedure describes onboarding only, or exists in draft and was never approved
Sample recent cloud onboardings	That new cloud services went through the defined process before use, including a security assessment and a named owner	Onboarding tickets, risk or security assessment records, approvals, owner assignment for a sample of recently added services	No assessment on file, approval given after the service was already live, no named owner
Check provider agreements and responsibility matrices	That the split of security responsibilities between the organization and the provider is written down and matches the contract and the provider's published terms	Signed agreements or terms, shared responsibility matrix per service, security and incident notification clauses	Responsibility matrix missing for key services, or the matrix does not match what the team actually operates
Verify security configuration of sampled services	That sampled cloud services are configured to the organization's requirements, such as access controls, logging and encryption settings	Configuration exports or baseline reports, screenshots dated within the audit period, results of configuration checks	Settings differ from the approved baseline, logging disabled, or no evidence of checks after go-live
Review ongoing management and review	That services are reviewed periodically and when they change, with the review recorded	Periodic review records, cloud usage or cost reports reviewed by the owner, change records for significant service changes	No review after onboarding, reviews done verbally with no record
Test the exit process	That the organization can leave a cloud service in a controlled way, including data return or deletion and removal of access	Documented exit steps, offboarding tickets for a sample of closed services, confirmation of data deletion or return and access revocation	Undocumented exit steps, retired services still holding data or active accounts
Search for cloud accounts outside the process	Whether cloud use exists that never passed through the process, such as accounts opened by teams or corporate cards	Cloud account inventory, billing or spend records, output from discovery tools or interviews about shadow IT	Accounts or subscriptions found in billing that are missing from the inventory
Interview service owners and administrators	That owners understand their responsibilities, the approved process and how they handle exceptions	Interview notes, owner acknowledgements, records of training or briefings on the cloud process	Owners unaware of the process or unable to name the provider responsibilities for their service

Implementing the cloud acquisition and exit process step by step

This sequence turns A.5.23 into a repeatable process that covers each cloud service from the first request to the return or deletion of data at exit. Each step ends with a record that an auditor can sample.

Define cloud security requirements
Start by stating what the organization requires from any cloud service before anyone evaluates a vendor. Information security, legal and business owners should agree on the data classes allowed in the cloud, the required hosting locations, encryption and key management expectations, logging needs, availability targets and the minimum contract terms. Record these as a cloud security requirements standard approved by management, and link it to the access control and classification rules already in place. The output is an approved requirements document that every later intake is checked against.
Run cloud service intake and risk assessment
When a team wants a cloud service, it submits a short intake form naming the service, business owner, data it will hold, integrations and expected users. Security reviews the request against the requirements standard, classifies the service and decides whether a full assessment is needed based on data sensitivity and criticality. The assessment covers provider security documentation, certifications the provider holds and their scope, data location, subprocessors and incident notification terms. Approve, approve with conditions or reject, and record the decision with the named risk owner. The output is a signed intake record and risk assessment entry in the register.
Document the responsibility split for each service
For each approved service, write down which security tasks the provider performs and which remain with the organization. Cover identity and access, configuration, data classification, encryption key choices, logging, backup, vulnerability management, incident response and secure deletion, using the provider's shared responsibility documentation as the starting point. Mark gaps where neither party is clearly assigned, and assign an internal owner to each customer-side duty. The output is a per-service responsibility matrix, reviewed by the service owner and security, and filed with the intake record. Confirm the provider's current documentation directly, since terms can change.
Configure and baseline the service
Before production use, configure the service to the approved requirements and the responsibility matrix. Enforce single sign-on and multi-factor authentication, apply least privilege roles, enable audit logging to a central location, set encryption and key management as decided, restrict network exposure and switch on provider security posture checks where available. Capture the settings as a baseline and compare it against the configuration standard, correcting any drift before go-live. Where the service runs on infrastructure you manage, such as a self-hosted platform in your own cloud account, configuration can also be kept as code so the baseline is versioned. The output is a signed baseline record with the configuration evidence attached.
Monitor and review service use
Once live, the service needs ongoing checks. Review access rights and administrative accounts on a set schedule, track configuration against the baseline, collect provider security notices and reports, and monitor logs for unusual use. Reassess the service when its data classification, users, integrations or provider terms change. Record each review with the reviewer, the findings and the actions taken, and feed significant issues into the incident and supplier monitoring processes. The output is a dated review log per service that shows the checks were performed and that findings were followed up.
Define the exit and data return process
Before the contract is signed, agree how the service will end. Document how data will be exported in usable formats, how the provider will return or delete data, how deletion will be confirmed in writing, how access and credentials will be revoked, and how a migration would be carried out if the service is replaced. Test the export path with a sample dataset where practical, and set a reminder to revisit the exit plan at each review. When the service is retired, carry out the exit steps, collect written confirmation of deletion from the provider, and close accounts. The output is an exit plan on file at onboarding and a closure record with the provider's deletion confirmation at the end.

Writing the provider responsibility split into your process

A.5.23 is only met if the organization can show, service by service, which security duties the cloud provider performs and which ones it keeps. Record that split as a named artifact in your cloud acquisition and use process, not as a general assumption. For each service you use, list the duties in rows and mark an owner for each: identity (who creates and removes administrator and workload identities, and how MFA and privileged access are enforced), configuration (who sets and monitors security settings such as storage exposure, network rules and encryption options), data classification (who decides what may be stored where and which regions are allowed), logging (who enables audit logs, where they are retained and who reviews them) and backup (who configures backups, sets retention and tests restores). Blank cells and shared cells are the findings auditors most often raise, so every row needs a single accountable party.

The split must be tied to each service because responsibility changes with the service model and with individual settings. A managed database, a virtual machine and a SaaS application can each leave the customer with a different set of duties, and the same provider can publish different shared responsibility descriptions for each. Confirm each row against the signed contract, the service terms and the provider's current security documentation, and record the document version and date you relied on. Provider certifications and audit reports are useful evidence that the provider's own controls were examined, but they do not show that your configuration, identities or data decisions are correct. Keep them in the file as supporting evidence for the provider's column only. Review the split when a service is added, a configuration option changes or the provider updates its terms, since a stale split is a common reason a cloud control appears to be implemented on paper but not in practice.

Evidence that satisfies A.5.23 and how to keep it current

A.5.23 is tested through records, not declarations. The artifacts below show that cloud services are acquired, used, governed and exited under documented security requirements. Each one needs a named owner and a review rhythm so that the evidence an assessor samples reflects the environment as it is today.

Cloud service register

A living list of every cloud service in use, including shadow services found through expense reports, identity logs and network data. For each entry, record the owner, the data classification, the hosting region, the contract reference and the date of the last security review. An assessor will often compare this register against cloud accounts and billing data, so gaps between the two are a common finding. Review it monthly and whenever a new account or subscription is created.

Approved cloud security requirements

A written baseline that every cloud service must meet before use, covering encryption, authentication, logging, data location and incident notification. Keep it aligned with the organization's information security requirements so that the acquisition process has a fixed standard to test against. Ask who approves changes to the baseline and confirm that the approval is recorded. Review it at least annually and after any significant change in regulation or in the provider landscape.

Per-service responsibility matrices

For each cloud service, a matrix that splits security tasks between the organization and the provider, such as identity configuration, patching, backup, encryption key management and logging. Providers publish shared responsibility documents, but the matrix must reflect the actual configuration and the contract terms your organization accepted. Re-check the matrix when the provider updates its shared responsibility documentation or when your configuration changes.

Onboarding risk assessments

A documented assessment completed before a cloud service goes live, recording the data it will hold, the threats considered, the controls required and the residual risk accepted by the owner. Attach the provider's independent assurance reports and note any gaps. Assessors look for evidence that the assessment happened before use, so keep dated versions. Reassess when the data classification changes or when the provider reports a material security event.

Configuration baselines and reviews

Hardened configuration baselines for cloud accounts and workloads, with scan results showing drift from those baselines. Open-source tools can run these checks: Wazuh Security Configuration Assessment uses YAML policies, mostly based on CIS benchmarks, that can be extended for your own rules, and Fleet policies can answer yes or no questions about managed endpoints. Confirm which checks apply to your providers, record exceptions with approvals, and review the results on a fixed schedule.

Cloud admin access reviews

Periodic reviews of who holds administrative roles in each cloud account, confirming that every privileged identity is still needed, correctly scoped and tied to a named person or an owned non-human identity. Export the role assignments, have the owner sign off, and retain the signed record. Test that leavers and movers were removed promptly by sampling against HR records. Shorten the review interval for the most privileged roles.

Exit plans and exercised exit records

A documented plan for leaving each critical cloud service, covering data export formats, deletion certification, replacement options and the contract terms that support migration. A plan alone is weak evidence, so record any exit that was exercised, including a partial test such as restoring data into another environment. Confirm the plan is updated when the provider, contract or data volume changes, and check that the exit clauses survive renewal.

What meeting A.5.23 costs in money and effort

The first cost of A.5.23 is building the cloud governance process: a cloud acquisition and onboarding procedure, a register of cloud services in use, and a responsibility matrix that records what the provider handles and what the organization must configure and monitor. Most of this work is documentation and decision-making, so the largest share of effort usually falls on the people who already know the systems: platform engineers, application owners and the security lead. Outside help, if used, typically covers facilitation, drafting and reviewing the matrix against the provider's published shared responsibility documentation.

Process design: writing the acquisition, use, management and exit procedures, and agreeing approval routes with procurement and legal.
Register build: listing every cloud account, subscription and SaaS service with its owner, data classification and business purpose.
Responsibility matrix: mapping each control area to the provider or the organization, per service type.
Exit planning: defining data return and deletion steps for each service of significance.
Tooling setup: deploying inventory and configuration checks, which is a one-time cost plus licensing if a commercial product is chosen.

Ask for the quote to name which of these deliverables are included and who signs off each one.

Open-source tools that support cloud configuration and asset evidence

This table compares four open-source tools that can produce evidence for A.5.23 on endpoints, devices and infrastructure, showing what each one records and the license terms to check before deployment. Read each row as one source of evidence within the wider cloud service arrangement, since none of these tools reads the configuration of a cloud provider's console on its own. The main takeaway is that these tools support the organization's own side of A.5.23 and do not replace the provider evidence the organization must collect separately.

Tool and license	Evidence it produces for A.5.23	Caveat for this control
Wazuh Security Configuration Assessment (GPL-2.0-only)	Pass or fail results from YAML policies that check files, directories, registry keys and running processes on monitored endpoints, with remediation advice	Covers monitored hosts, not the provider's cloud control plane; custom policies must be written and maintained by the organization
Fleet policies (MIT)	Yes or no device checks written as osquery queries, with per-device pass or fail views for each policy	Shows device state only; the organization must define which policies map to the cloud service requirements it set
GLPI Assets (GPL-3.0-or-later)	Inventory of computers, software, network equipment and racks, entered manually or pushed by the GLPI Agent through native inventory since version 10	Records what the organization runs; cloud resources and provider-managed services need manual entries or separate import
Zabbix host inventory (AGPL-3.0-only)	Device type, serial number, location and responsible person for each host, entered manually or filled from agent data such as hardware, OS and packages	Owner and location fields are only as current as the process that updates them; AGPL terms apply if the modified service is offered over a network
Provider console evidence (not covered by these tools)	Account settings, configuration baselines and audit logs held by the cloud provider and exported by the organization	Needs its own collection and retention process; confirm with each provider which reports and certificates are available under the contract

Who owns A.5.23 and what is worth outsourcing

A.5.23 asks for cloud services to be acquired, used, managed and exited in line with your information security requirements. That means the organization owns the decisions: which cloud services are acceptable, under what conditions, who approves them, and how the business gets its data back when a service ends. No implementation partner or auditor can make those calls for you, and an auditor will ask who made them and when.

Acceptance decisions: Set the criteria a cloud service must meet before use, and record who approves each service and the risk accepted at that point.
Shared responsibility ownership: Decide which security controls belong to you and which the provider covers, then assign a named owner for each side of that split.
Ongoing management: Review provider security reports, changes to terms and incidents, and decide what to do when a service falls short.
Exit decisions: Define when a service is retired, how data is returned or deleted, and who verifies the deletion.
Policy and approval records: Keep the cloud rules inside the information security policy framework and the approvals that show they are followed.

Before engaging any outside party, confirm internally who will sign off on cloud acceptance and exit, because those sign-offs cannot be delegated to a partner.

Gaps that cause A.5.23 findings and how to close them

Most A.5.23 findings trace back to a small set of recurring gaps: cloud services nobody registered, responsibilities nobody wrote down, and exit and access arrangements that exist only on paper. Each card below names one gap, why an assessor treats it as a finding, and the single action that closes it. Work through them in order, because the register comes first and the other checks depend on it.

Shadow SaaS outside the register

Teams often sign up for cloud tools with a corporate card or a free trial, and those services never reach the list of cloud services the organization manages. An assessor who finds a live service that is missing from the register will question whether the acquisition process under A.5.23 operates at all. Start by reconciling the register against single sign-on logs, expense records and DNS or egress data. Then confirm that each service has an owner, a classification and a documented approval.

Responsibility split assumed, not written

Teams frequently assume the provider handles patching, backups or encryption, when the contract and the provider's shared responsibility documentation divide those tasks differently. A.5.23 expects the split to be understood and managed in line with the organization's information security requirements. For each service, record which party performs each security function, where that is documented, and who checks it. Pay close attention to customer-configured settings, which remain the organization's job.

No review after onboarding

A cloud service is usually assessed once, during purchase, and then left alone while its features, sub-processors and data locations change. Assessors look for evidence that the service is reviewed during use, not only when it is approved. Set a recurring review for each material service that covers provider security documentation, changes to terms, incidents reported by the provider, and the organization's own usage. Keep the review record with the register entry so the two stay in step.

Exit plans never tested

An exit plan that lists steps but has never been run gives an assessor little confidence that data can be retrieved, deleted or moved when a contract ends or a provider fails. A.5.23 covers exit as part of the cloud service life cycle, so the plan should name the data to be exported, the format, the deletion evidence the provider will supply and the time needed to restore service elsewhere. Run a partial export for at least one service, confirm the data opens, and file the deletion certificate or provider confirmation as evidence.

Cloud admin access not reviewed

Administrator accounts in cloud consoles and tenant portals can change every control that the organization relies on, yet they are often granted once and never reviewed. Assessors will sample these accounts against the access rules that apply to the cloud service. List every cloud administrator, the role each holds, whether multi-factor authentication is enforced, and when access was last confirmed by a manager. Remove accounts that no longer have a business reason to exist, and keep the review output as dated evidence.

Configuration drift without evidence

Cloud settings change through consoles, scripts and provider updates, and a configuration that passed review last quarter may not match today. Without a baseline and a record of checks, the organization cannot show an assessor that the agreed settings still apply. Define a baseline for each material service, scan it on a schedule, and keep the results. Open-source configuration assessment tools such as Wazuh can run policy checks against endpoints, but cloud settings often need separate posture tooling, so confirm coverage for each provider in use.

Questions buyers ask about A.5.23 cloud controls

How much effort does A.5.23 take to implement?

The effort depends mostly on how many cloud services the organization uses, how much of its production runs in them, and how many of those services already have documented owners and security settings. A.5.23 asks for established processes covering acquisition, use, management and exit, so the work is largely one-time design followed by recurring operation. Start by listing every cloud service in use, including ones bought by individual teams. Then ask a cost-sensitive question of any outside party: what is in the written scope, which services are covered, and which deliverables (procedure, register, review records) are included. No duration figure is given here because none is supported by a researched source; confirm expected effort with your certification body and the implementer in writing.

Can a small team run A.5.23 in-house?

Yes, a small team can usually run A.5.23 in-house if one person owns the cloud service register and the process is kept short enough to follow. The control needs a documented way to approve new cloud services, a record of who manages each one, a periodic check of the provider's security terms and settings, and a plan for leaving a provider. Those are ordinary administrative tasks, but they fail quietly when nobody owns them, typically when a team signs up for a tool on a corporate card. Keep the procedure to what people will actually follow, and test it by sampling two or three recent cloud purchases. If the team lacks engineering capacity to check configurations, that is the part most often bought in.

What does the organization have to own, and what can a partner prepare?

The organization owns its controls, its risk decisions and its cloud accounts. A.5.23 makes the organization responsible for setting its own information security requirements for cloud use and for enforcing them, even when a provider runs the platform. An implementation partner can help draft the acquisition and exit procedures, set up the evidence sources and collect configuration records. A partner cannot accept risk on the organization's behalf, sign the provider's contract, or issue an audit report or certificate, which only an independent auditor or certification body does. Ask any partner to put in writing which artifacts it delivers and which decisions remain with named internal owners.

How is cloud evidence different from endpoint evidence?

Cloud evidence records decisions and settings about services you do not run on your own hardware, while endpoint evidence records the state of machines you control. For endpoints, an assessor can often look at a running device and its scan results. For cloud services, the useful evidence is usually the approval record for the service, the contract or terms accepted, the configuration baseline, access review records, the provider's independent assurance reports you hold, and the exit plan. Operational tooling can help: Wazuh's Security Configuration Assessment checks monitored endpoints against YAML policies, and Fleet policies answer yes or no questions about devices. Those tools cover your endpoints, so they do not replace cloud service records, and you should confirm what each tool can read in your own cloud accounts.

Does a cloud provider's certificate satisfy A.5.23?

No. A provider's ISO/IEC 27001 certificate or other assurance report does not satisfy A.5.23 for your organization on its own. The certificate covers the provider's own management system and scope, not your choice of services, your configuration, your access rights or your exit arrangements. Assessors generally expect you to review the provider's assurance evidence as one input, check that its scope includes the services you use, and record how you responsibly configured the parts that remain yours. Confirm the certificate's scope and validity through the IAF CertSearch database that ISO points to, and read the split of responsibilities in the provider's documentation.

How does A.5.23 relate to A.5.19 to A.5.22?

A.5.23 is a cloud-specific application of the supplier controls. A.5.19 sets how supplier risk is assessed, A.5.20 puts security requirements into agreements, A.5.21 covers risks further down the ICT supply chain, and A.5.22 covers monitoring and change management of supplier services. A.5.23 applies these to acquiring, using, managing and exiting cloud services, with the provider split of responsibilities made explicit. In practice, one cloud due diligence record can serve several controls, but each control still needs its own evidence. NIST's crosswalk relates A.5.23 to supplier-related controls such as SA-9 and SR-5, which is a useful starting point for mapping. Confirm any mapping you rely on with your certification body.

What is ISO/IEC 27017 and should we read it for A.5.23?

ISO/IEC 27017 gives cloud-specific guidance on top of ISO/IEC 27002, for both cloud service customers and cloud service providers, and it adds controls. Read it if your organization is a cloud customer that needs to understand the provider split of responsibilities, or if you also deliver cloud services to others. Its edition 2 was published in July 2026 according to ISO, so check that you are reading the current version before citing it. The standard is an interpretation aid, not a certification, and whether it is in your certification scope depends on how your certification body and your statement of applicability treat it.

How DeployOpen prepares A.5.23 cloud evidence

DeployOpen plans and implements self-hosted open-source platforms inside the client's own infrastructure, and prepares the processes, systems and evidence that support A.5.23 Information security for use of cloud services. The organization owns its cloud decisions and controls, and an independent certification body issues any certificate.

How we scope

Engagements are fixed-scope, with cloud services, providers and responsibilities agreed in writing before work starts
The scope lists which cloud acquisition, use, management and exit processes are covered by the engagement
Provider responsibility splits are mapped against your own requirements so ownership of each control is explicit

How we build

We configure self-hosted open-source tooling for cloud asset inventory, configuration checks and access reviews
Security configuration assessment and policy checks are set up to produce records you can show an auditor
Testing of cloud configurations and controls is documented so you can confirm the processes operate as written

How we hand over

Process documentation covers acquisition, onboarding, monitoring, change and exit steps for each cloud service in scope
Evidence packs list what each record proves, where it is stored and how often it is produced
Handover includes operating runbooks so your own staff can run the processes after the engagement ends

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the initial handover
Retainers can cover periodic evidence reviews ahead of your surveillance or recertification audits
Ask your certification body which evidence it samples for A.5.23 so the scope matches its expectations