Does Ceph encryption alone satisfy PCI DSS 3.5 for stored card data?
Encrypted OSDs alone do not meet requirement 3.5.1 for stored primary account number (PAN). Encryption at the drive or OSD level protects media that leaves the data center, but it does not render PAN unreadable to anyone who can read the data through the storage interface. Requirement 3.5.1.2 accepts disk-level or partition-level encryption as the only protection solely for removable electronic media, and that allowance became mandatory on 31 March 2025. A Ceph cluster holding PAN in RBD images, CephFS files or RGW objects is not removable media, so the team needs a protection method that 3.5.1 itself accepts: one-way keyed hashes, truncation, index tokens, or strong cryptography with key management applied to the data or to the objects holding it. On Ceph, the practical options are application-level encryption before the write, or server-side encryption in RGW backed by keys the organization manages. Each choice moves key custody and decryption rights to a different team, so decide that first.
Ceph helps with the parts of 3.5 that are about where copies end up. Backups, replicas, RBD and CephFS snapshots, mirrored or multisite copies, and log streams can all hold PAN, and the standard expects them to be protected or excluded from scope. Ceph does not decide that for you. Inventory every pool, bucket, snapshot schedule, backup target and log sink that could receive card data, then state for each whether it is in the cardholder data environment (CDE). Where a log or backup must contain PAN, the protection must match the primary store. Where it does not, the team should prevent capture at the source. Encrypted messenger v2 secure mode, described in the Ceph msgr2 documentation, protects traffic between daemons and clients, but it is a transit control and does not satisfy the stored-data requirement by itself.
What remains with the organization is the approach decision, the key custody policy, and the assessment. Choosing between the defined approach and the customized approach, documenting the rationale, and deciding who may hold decryption keys belong to the entity and its QSA or assessor. DeployOpen can design the Ceph configuration, key workflow, backup scoping and evidence, and prepare the system and records an assessor will test, but it does not issue a Report on Compliance or an Attestation of Compliance. The PCI Security Standards Council does not enforce compliance; the payment brands decide who must validate and run enforcement. Confirm your validation level and the applicable SAQ or ROC path with your acquirer or payment brand before the design is fixed, because that determines the evidence you need to collect.
Mapping requirement 3.5.1 and 3.5.1.2 to Ceph capabilities and configuration
This table compares each part of PCI DSS requirement 3.5 with the Ceph capability that might address it, the configuration to confirm, and whether that capability can stand on its own. Read the last column as the key takeaway: encrypted OSDs protect drives, but they do not by themselves make stored PAN unreadable to people or processes with access to the cluster.
| Requirement or storage location | Ceph capability | Configuration to confirm | Satisfies the requirement alone |
|---|---|---|---|
| 3.5.1: one-way keyed hashes, truncation, index tokens or strong cryptography with key management | Application-level encryption or tokenization in the cardholder data application, with keys held outside the cluster | Where PAN is encrypted, who holds the keys, key rotation procedure, and whether the key store is separate from Ceph admin accounts | No |
| 3.5.1 as applied to RGW objects holding PAN | RGW server-side encryption with managed keys, if your Ceph release and key source support it | Encryption mode, the external key management service used, key access policy, and whether the mode is confirmed for your release before design sign-off | Not applicable |
| 3.5.1.2: disk or partition encryption as the only PAN protection | OSD encryption (dm-crypt) on the drives that store PAN | Encryption enabled on every OSD, key handling for OSD keys, and whether a stolen drive is the only threat it addresses | No |
| 3.5.1.2 scope note: removable media only | Not applicable to fixed cluster drives in a data center | Confirm that no PAN is written to removable media or exported drives that depend on disk-level encryption alone | No |
| Data in transit between clients, OSDs and monitors | msgr2 secure mode, which encrypts post-authentication traffic | Secure mode enabled cluster-wide, client settings aligned, and TLS on RGW endpoints where clients reach the gateway | No |
| Backups of PAN-bearing data | Replicated or backup pools and RGW copies, which are copies of the same data and carry the same PAN exposure | Backup encryption with keys separate from production, backup account access, and retention periods documented in your data inventory | No |
| Logs and audit trails that may capture PAN | Log pipelines and RGW access logs outside the cluster, handled by other tools | Log content review for PAN, masking or tokenization at source, and where log storage is encrypted and access controlled | No |
| Assessor evidence for the whole storage path | Configuration exports, key management records and the data flow diagram | Ask your QSA which combination of approaches they will accept for each storage location before implementation starts | Not applicable |
Which encryption layer protects stored PAN on Ceph
Encrypting OSD devices protects drives that leave the data center or are discarded, because the bytes on the media cannot be read without the key. It does not change what happens once the cluster serves a read. Every authorized client, gateway and administrative path receives plaintext, so anyone who can reach a pool through an RBD map, CephFS mount or gateway bucket reads PAN as normal. Requirement 3.5.1.2 accepts disk or partition encryption as the sole protection only on removable electronic media, so for a fixed storage cluster it cannot be the only control.
- Who holds the keys: the platform team or the provisioning tooling that prepares each OSD, usually on the same hosts that store the data.
- What it protects: lost, stolen or decommissioned drives. It does nothing for reads through the cluster.
- Where it stops: any authenticated client with pool access receives decrypted PAN.
- Operational cost: key escrow, rotation and recovery procedures must be designed in advance, or a failed host can strand data.
Confirm with your assessor whether the disk layer will be treated as a supporting control in your design and which evidence of key custody they will request.
With server-side encryption at the Object Gateway, the gateway encrypts objects before they are written to the underlying pools and decrypts them for authorized requests. The available modes and key store integrations depend on your Ceph release, so confirm them against the Object Gateway documentation for your exact version before you design around them. Once the gateway decrypts data for a reader, the protection comes from access control to the bucket and the key store. Auditors will ask who can call the key store and who can read the bucket.
- Who holds the keys: this depends on the mode. Some modes let the client supply the key, and others place keys in an external key service.
- What to confirm: the supported modes, key store backends and minimum versions for your release.
- Access boundary: bucket policies, IAM roles and user accounts determine who receives plaintext.
- Key lifecycle: rotation, revocation and recovery of keys held in the external store.
- Copies and versions: multipart uploads, object versions and replicas must follow the same encryption scheme.
Ask the vendor or your architect for a written test showing that an unauthorized identity cannot read an object and that the key store denies the same identity.
Application-level field encryption encrypts the PAN before it reaches Ceph, so the storage layer holds only ciphertext and the key stays outside the cluster. This is the only option in this group where a database or object reader cannot recover PAN without the application's key path. The cost moves into the application, because key management, searching and performance all change. Requirement 3.5.1 accepts strong cryptography with key management, and key management is where most designs fail review.
- Who holds the keys: the application or a separate key service, with access separated from Ceph storage administrators.
- What it protects: PAN in database files, RBD volumes, objects and any backups made from them.
- Search and reporting: equality lookups need an index token or keyed hash design, because ciphertext cannot be matched or sorted directly.
- Key scope: separate keys for each environment and data set, with documented rotation.
- Plaintext windows: memory, logs, caches and error messages must never carry PAN.
Have your assessor review the key management design and the plaintext exposure in application code before you rely on this layer for scope decisions.
Tokenization or truncation removes full PAN from the stored data set, so Ceph holds a token, a truncated value or a keyed index that a storage reader cannot convert back into the card number. Requirement 3.5.1 names truncation, index tokens and one-way keyed hashes among its accepted methods. The trade-off is that the original PAN lives somewhere else, usually a token vault or payment provider, and that system becomes the controlled environment. Whether the design reduces scope depends on the whole data flow, not on the storage product.
- Who holds the values: a token vault or payment provider holds the mapping, separate from the Ceph cluster.
- What remains on Ceph: tokens, truncated numbers or keyed hashes, each checked against the 3.5.1 options.
- Reversibility: tokens that can be detokenized keep the vault in scope. One-way forms cannot be reversed.
- Scope claims: removing PAN from Ceph does not remove the systems that still receive or transmit card data.
- Backups and logs: confirm that snapshots, replicas and logs contain only the reduced form.
Request a data flow diagram that shows every point where full PAN exists, and have your assessor confirm the scope before you depend on it.
Configuration sequence for PAN storage on Ceph
This sequence fixes the PCI DSS version and scope first, then chooses how stored primary account numbers are protected before any Ceph setting is changed. Ceph encryption and transport controls are then layered on top as defense in depth, and the result is a documented key custody and rotation record that an assessor can test.
Confirm PCI DSS version and scope with the assessor
Agree with the assessor, or with the payment brand or acquirer that requires validation, which PCI DSS version applies and which systems are in scope. PCI DSS v4.0.1 is the only active version, so the assessment should reference it and not v4.0 or v3.2.1. Ask the assessor to confirm whether the Ceph cluster, its RGW endpoints, its backup targets and its log stores are in the cardholder data environment or connected to it. Output: a written scope statement that names every Ceph pool, bucket, RBD image or CephFS path that may hold PAN, plus the cluster administrators who could affect those systems.
Decide the requirement 3.5.1 method for each data store
For each place PAN is stored, choose one method allowed under requirement 3.5.1: a one-way keyed hash of the full PAN, truncation, index tokens, or strong cryptography with key management. Disk-level encryption on Ceph OSDs does not qualify as the sole protection for stored PAN on fixed storage, because requirement 3.5.1.2 limits that approach to removable electronic media. Record the chosen method per data set, including backups and logs, and confirm the interpretation with the assessor before building. Output: a data-store register that maps each Ceph pool or bucket to its 3.5.1 method and its owner.
Protect PAN in the application or tokenize before Ceph
Place PAN behind application-level encryption or a tokenization service so that Ceph only receives ciphertext or tokens. The key-encryption keys should be held in a key management system outside the data path, not in the Ceph cluster, its configuration or the same cephadm-managed hosts that run the OSDs. Test by writing a known test PAN through the application and confirming that the raw object or block contents in Ceph contain no readable card number. Output: a test record showing that a search of the stored objects and volumes returns no clear PAN, and a description of where each key is held.
Configure RGW or RBD encryption as a defense layer
Enable Ceph-side encryption as an additional layer for the chosen storage interface. For S3 objects, review the Ceph Object Gateway server-side encryption options and their key source, and confirm with your Ceph version that the managed-key integration you need is supported. For RBD volumes, review the encryption options available for images and confirm them against the release you run. Ceph encryption does not replace the application-level protection in the previous step, so document it as a supplementary control. Output: a configuration record listing the bucket or image encryption settings, the key provider for each, and the test that proves new objects are encrypted at write time.
Enable msgr2 secure mode for Ceph traffic
Set the messenger to secure mode so that all post-authentication traffic between clients, monitors and OSDs is encrypted with AES-GCM and checked for integrity. Msgr2 uses port 3300 by default, so confirm that firewalls and load balancers allow it and that legacy clients support it before you enforce the setting. Also confirm with your Ceph release notes whether secure mode affects client connections from virtualization or backup hosts. Output: a cluster configuration showing secure mode enforced and a packet or connection check that confirms encrypted sessions from each client type.
Restrict cephadm host and dashboard access
Limit SSH access to cephadm-managed hosts to named administrators, and limit the Ceph Dashboard to the administrators who need it, with single sign-on where your environment supports it. Remove or disable default accounts, and keep the dashboard off untrusted networks. Separate the administrators who can read or change PAN-bearing pools from those who manage the cluster, and log every privileged action. Confirm with your Ceph release which dashboard authentication and SSO options apply to your deployment. Output: an access matrix that names each role, its permitted actions and the logs that record them.
Document key custody and rotation
Write down who creates, stores, rotates and destroys each key used for PAN protection and Ceph encryption, and where the key material lives. Define the rotation trigger and procedure, including how older ciphertext is re-encrypted or retained, and how keys are restored if the key system fails. Include backups and logs that contain PAN in this scope, because requirement 3.5 covers non-primary storage too. Confirm the rotation and custody details with your key management vendor and your assessor. Output: a key custody standard and a dated rotation log that the assessor can sample, along with evidence that a test restore of an encrypted backup succeeded using the documented key process.
Evidence an assessor will ask for from the Ceph layer
An assessor testing PAN protection on Ceph will ask for proof that encryption, keys, transport settings, access and backup scope are configured as described and stay that way. Each artifact below should be generated or reviewed on a schedule, not assembled only when the assessment starts. The assessor judges this evidence against PCI DSS requirements; DeployOpen helps prepare it but does not validate it.
Encryption configuration exports
Keep dated exports of the cluster and pool settings that show which storage holds PAN and how it is encrypted, including OSD encryption status and any RGW server-side encryption settings. Compare each export with the data inventory so every pool that stores card data is accounted for. Note that OSD-level encryption alone does not satisfy requirement 3.5.1, so the export must be paired with an application or RGW control that renders the PAN unreadable. Re-export after every configuration change and after each Ceph release upgrade.
Key management records and rotation logs
Record where encryption keys are generated, who can read them, and where they are stored, including any external key management service. Rotation logs should show each key change, its date, the approver, and the re-encryption or re-wrapping work that followed. Assessors will sample a rotation and trace it back to the policy, so confirm that the log entries match the key IDs that appear in the configuration exports. Gaps usually appear where keys were rotated by hand and not recorded.
Msgr2 secure mode settings
Capture the messenger settings that enforce secure mode for client and inter-daemon traffic, because card data crossing the cluster network is in scope for transmission protection. Show the effective configuration on monitors, OSDs and gateways, not only the intended value in a file. Check whether any legacy or unencrypted listeners remain on the network, and record the results of that check. Confirm the protocol behavior for each Ceph release in use with the vendor documentation before you cite it in an assessment.
Access control lists for RGW and dashboard accounts
Export the list of RGW users, sub-users, access keys and bucket policies, along with the dashboard accounts and their roles. Each entry should map to a named owner and a documented reason for access to buckets that hold PAN. Remove unused keys and shared accounts before the export is taken, and record the review date. Assessors commonly test whether administrators who can read storage can also read keys, so show that these roles are separated.
Backup and log scoping inventory
Build an inventory listing every backup target, replica, snapshot, log sink and monitoring store that might receive PAN, with its location and retention period. Requirement 3.5 also reaches non-primary storage such as backups and logs, so each row needs either a protection method or a documented reason it holds no PAN. Log entries often capture full card numbers from application errors, so sample them and record the findings. Update the inventory whenever a new replication or logging path is added.
Restore test records
Keep records of restore tests that cover encrypted PAN data, showing the source, the target, the date, the person who ran the test, and whether the decryption keys were available at restore time. A restore that succeeds only because the original cluster still runs does not demonstrate recovery. Include failed attempts and the corrective action, since assessors read these as evidence of control operation. Schedule the tests in the same calendar as the key rotation and inventory reviews so the records stay consistent with each other.
Scoping backups, snapshots and logs that hold card data
Requirement 3.5 is not limited to the production database. The SAQ D notes to 3.5.1 make clear that non-primary storage such as backups and logs falls within it, so every Ceph copy that can hold a PAN needs the same protection as the primary or must be proven free of PAN. On a Ceph platform that list is longer than most teams expect: replicas or erasure-coded shards of the pool holding card data, RBD and CephFS snapshots, RGW object versions kept under a bucket versioning policy, multisite secondary zones, mirrored RBD images, exported backup archives, and the log pipeline that receives application output from the same workloads. Each of these is a place where a PAN can persist after the primary record is changed or deleted.
Start with an inventory that maps each pool, bucket, image, filesystem and log index to the data it holds, the component that writes it, and the people or service accounts that can read or restore it. Ask the application owner to confirm which fields are PAN, which are tokens, and which are truncated values, because the answer decides whether a copy is in scope at all. Then record the retention settings for each copy, including snapshot schedules, RGW lifecycle rules, and multisite sync behavior, and confirm the values with your own policy owner. This document should not rely on retention periods that were never approved. Where card data can be removed from a copy, such as by tokenizing before logging or by excluding the field from the log shipper, that change usually reduces scope more than adding controls to every copy.
What the Ceph platform does not cover for PCI DSS
Encryption on Ceph protects the storage layer, but PCI DSS is assessed across the whole cardholder data environment. The cards below set out what sits outside the platform and what your assessor and your teams still need to settle before the storage design can be called compliant.
The PCI DSS assessment itself
Compliance is shown through a Report on Compliance completed by a Qualified Security Assessor, or through a Self-Assessment Questionnaire, and in both cases an Attestation of Compliance. A certificate is not accepted as validation. Ask your payment brands or acquirer which assessment type applies to your entity, and plan the Ceph evidence (configuration exports, key policies, restore test records) so your assessor can test it directly.
Defined or customized approach
Each requirement can be met through the defined approach or, if your organization has robust security and risk management, through the customized approach. Choosing the customized approach for requirement 3.5 means documenting the stated objective, how Ceph meets it differently, and the testing your assessor will need. Decide this early, because it changes the evidence you collect from the cluster.
Key custody outside Ceph
Encrypted OSDs do not give you a key policy. The keys that protect stored PAN, and the process for rotating, revoking and recovering them, must be held in a key manager you can document, such as an HSM or an external KMS that your team controls. Confirm who can read key material, how access is logged, and how keys are backed up, because each of these answers belongs in your key management evidence.
FIPS validation questions
Whether a Ceph build, its cryptographic modules and the RGW encryption path are validated under FIPS 140 is a question for your vendor and your QSA, not something this page can settle. Ask for the exact cryptographic modules in your release, the operating system crypto library used by your hosts, and any validation certificate numbers, and record the answers before the design review.
Application code and tokenization vendors
Where the application writes PAN, the storage design only protects what lands on disk. Logging frameworks, caches, export jobs and any tokenization or payment vendor that handles card data may hold PAN outside the cluster. Map every data flow that carries card data, and confirm which of those components are in scope, because an encrypted bucket does not cover a debug log written by the application.
The other eleven requirements
Requirement 3.5 is one of twelve principal requirements grouped under six goals, and the assessment covers network security, access control, vulnerability management, logging, monitoring and policy as well. Encryption on Ceph does not satisfy segmentation, MFA for administrators, or patching of the hosts and Ceph releases. Review the full requirement set against your platform, and plan how each Ceph control maps to the evidence your assessor requests.
Questions teams ask before scoping PCI DSS work on Ceph
Are encrypted OSDs enough to satisfy PCI DSS requirement 3.5 for stored card data?
No. Encrypted OSDs protect drives that are removed or stolen, but requirement 3.5.1 expects the stored primary account number to be unreadable through one of its listed methods, such as strong cryptography with key management, truncation, index tokens or one-way keyed hashes. Disk-level encryption is accepted as the only PAN protection only on removable electronic media, so a Ceph cluster holding cards in ordinary pools needs an application-level or gateway-level control on top of OSD encryption. Any RGW server-side encryption must be backed by keys your team manages and rotates. Confirm the approach with your QSA before you build.
What does PCI DSS work on Ceph cost, and what is included?
DeployOpen does not publish a price list. A quote follows from the written scope, which should name the data flows, the systems that store or back up card data, the key design, and the deliverables such as configuration evidence and runbooks. The assessor is paid separately by you for the Report on Compliance or Self-Assessment Questionnaire, and that fee depends on the assessor's own scope. Ask any quote to separate one-time build work from recurring items such as key rotation reviews, backup restore tests and retained evidence collection, and to state which items depend on your QSA.
Which factors make PCI DSS work on Ceph cost more or less?
The main drivers are the number of systems that touch card data, the number of copies of that data, and the key design. Each extra location holding PAN, such as a replica pool, a multisite zone, a backup target or a log store, adds encryption, access control and evidence work. Key design matters because a single managed key service is simpler to assess than many per-application keys with unclear owners. Assessor time also grows with the number of data flows and exceptions you ask them to test. A narrow scope that keeps card data in one well-defined pool usually costs less to build and to assess.
How long does PCI DSS scoping and implementation on Ceph take?
The duration depends on the scope, the number of environments and how quickly your team can supply information and approve changes. No timeline is set without a written scope, so ask for a schedule with dated milestones before you commit. Plan for at least three phases: confirming the data flows and scope with your QSA, building and testing the encryption and key controls, and collecting evidence for the assessment. Ask whether the schedule includes time for the assessor's review and for a restore test of any backup that holds card data.
Can our own team handle PCI DSS work on Ceph without a partner?
Yes, if your team already runs Ceph in production and has people who can work with a QSA on scope, key management and evidence. The hard parts are less about cipher settings and more about proving scope: showing every pool, gateway, snapshot, backup and log store that holds PAN, and showing who can read it. Teams without that combination often use a partner for the build and keep the assessment internal. Check whether your team has someone who owns the key lifecycle, someone who can run restore tests, and someone who can answer the assessor's questions in writing.
What does our team need to provide before PCI DSS scoping on Ceph starts?
Start with a data flow map that shows how card data enters, moves through, and leaves the cluster, including backups, logs and any replicas or snapshots. Name the key owners and the process for key rotation and recovery. Provide access lists for every account and role that can read the relevant pools, buckets and log stores, and the network paths between them. Schedule a conversation with your QSA early so that scope decisions are agreed before the build. Missing information here is the most common cause of rework, so gather it before asking for a quote.
Did PCI DSS v4.0.1 change requirement 3.5.1.2 on disk-level encryption?
No. PCI DSS v4.0.1, published on 11 June 2024, was a limited revision of v4.0 with no requirements added or deleted. The disk and partition encryption clause, 3.5.1.2, was one of the future-dated requirements from v4.0. It accepts disk-level or partition-level encryption as the only PAN protection only on removable electronic media, and that requirement became effective on 31 March 2025. Because v4.0 retired on 31 December 2024, v4.0.1 is the only active version. Confirm the exact wording and your assessment approach with your QSA, since the standard itself is the authority.
What a PCI DSS 3.5 engagement on Ceph involves
A PCI DSS 3.5 engagement on Ceph moves through four phases: planning, a scoping workshop with the assessor, configuration, and evidence collection with handover. The planning phase starts with the client's architecture: which pools, RGW buckets, RBD images and CephFS file systems hold PAN or sensitive authentication data, which hosts and monitors sit in the cardholder data environment, and which backup targets and log stores receive copies. Before any configuration, the client should confirm who owns each key, who can rotate it, and who approves access to the KMS, because the protection design depends on those answers. The client also provides the data flow diagrams and the list of people who hold administrative access to the cluster and the key service.
The scoping workshop brings the assessor, the client's compliance lead and DeployOpen into one room with the data flows on the table. The purpose is to agree which storage components fall inside the cardholder data environment, which protection method applies to each store under the defined or customized approach, and how backups and logs are handled. Requirement 3.5.1.2 cannot be used to justify disk-level encryption as the only protection for stored PAN outside removable media, so the workshop should record that decision in writing before build work starts. DeployOpen then configures the agreed controls, such as application-level protection or RGW server-side encryption with an external key manager, and writes runbooks for key rotation, access review, restore and incident response.
Evidence collection and handover close the engagement. DeployOpen assembles an evidence pack that maps each configured control to the requirement it supports, with configuration exports, access lists, test results and restore records, and the client confirms the pack is complete before the assessor reviews it. The client keeps responsibility for the Report on Compliance or Self-Assessment Questionnaire and the Attestation of Compliance, since DeployOpen prepares evidence but does not issue or validate an assessment. Ask in advance which assessor will review the design, how many review cycles the quote includes, and who maintains the runbooks after handover, since the PCI SSC's future-dated requirements and next iteration of the standard can change what evidence is expected.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside infrastructure you control, including Ceph. For cardholder data on Ceph, we start by settling where stored PAN actually lives, then build and document the controls that protect it, and we prepare evidence for your assessor without issuing any audit report or attestation ourselves.
How we scope
- We map every Ceph pool, RGW bucket, RBD image and CephFS path that could hold PAN, including backups, snapshots and logs.
- The written scope states which PAN protection method applies to each store, such as strong cryptography with key management or an alternative permitted by requirement 3.5.1.
- Engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before any build work starts.
How we build
- We configure RGW server-side encryption or application-level encryption against your chosen key management service, with key custody kept under your control.
- We set up backup and log pipelines so card data is either excluded, tokenized or encrypted before it reaches any non-primary store.
- We test that encrypted objects cannot be read from raw OSD or backup media without the managed keys, and record the results.
How we hand over
- You receive a data flow diagram, a PAN location register and a key lifecycle runbook covering creation, rotation, access and retirement.
- Configuration baselines, test scripts and results are delivered as versioned files in your own repositories.
- We document the controls and evidence mapped to requirement 3.5 so your QSA or internal assessor can test them, while the assessment itself stays with them.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, covering Ceph release changes and key rotation events.
- We re-check the PAN location register when new buckets, backup targets or log sinks are added to the cluster.
- Ask any provider to confirm in writing which PCI DSS version and assessment route they are designing against before accepting the quote.
