Should a bank on Swift and card processing pursue SWIFT CSCF vs PCI DSS together?
For a bank or payment institution that is connected to Swift and also processes cardholder data, the CSCF and PCI DSS are not alternatives. Most such institutions must do both. The CSCF is the obligation that attests to the local Swift footprint: each user implements the controls, has them independently assessed and attests compliance annually in the KYC-SA application. PCI DSS is the obligation that validates the cardholder data environment, documented on a Report on Compliance completed by a Qualified Security Assessor or on a Self-Assessment Questionnaire, each with an Attestation of Compliance. Which one applies to a given system depends on where that system sits, not on the institution as a whole. Payment brands, acquirers and Swift each decide what they require from you, so confirm those requirements in writing before you choose a sequence.
The sequencing question usually comes down to scope. Start by mapping which systems sit on the Swift footprint, which store, process or transmit cardholder data, and which do both, such as a shared jump host or a payments gateway that also sends Swift messages. Those overlap systems are where a single set of evidence, such as access reviews, vulnerability scans and penetration test reports, can serve both assessments. The condition that changes the plan is a shared environment. If the Swift infrastructure and the cardholder data environment share network segments, administrators or identity systems, the assessors for both obligations will examine the same controls, so the scope definitions must agree before fieldwork starts. If the environments are fully separated, you can run the two cycles with less shared evidence.
DeployOpen plans, implements and documents the controls, and prepares the evidence and scope mapping that both assessments need. We do not issue the CSCF attestation, the ROC, the SAQ or the AOC. Those come from Swift's assessment process and from a QSA or your own qualified staff, as the rules for each require. Before you commit budget, ask your assessors which evidence they will accept from the other obligation, and confirm which PCI DSS version your QSA will use, since the active version and any future-dated requirements affect what you must prove.
How the CSCF and PCI DSS differ on scope, controls and proof
This table compares who owns each framework, who must comply, what each protects, how each is structured and what evidence each produces. Read it to see where one evidence set can serve both and where the two assessments diverge.
| Dimension | SWIFT CSCF (v2026) | PCI DSS (v4.0.1) |
|---|---|---|
| Owner | Swift, through its Customer Security Programme | PCI Security Standards Council, which does not enforce compliance |
| Who must comply | Every Swift user, assessed through its own architecture type | Entities that store, process or transmit cardholder data, or could affect the cardholder data environment |
| What is protected | The local Swift footprint and the access and messaging paths into it | Cardholder data and sensitive authentication data, and the systems that touch them |
| Structure | 32 controls: 26 mandatory and 6 advisory, grouped under three objectives | 12 principal requirements grouped under six goals |
| Scope driver | Architecture type A1, A2, A3, A4 or B determines which controls apply | Where cardholder data flows and what could affect the cardholder data environment |
| Current version | CSCF v2026, attested between July and December 2026 | PCI DSS v4.0.1, the only active version after v4.0 retired on 31 December 2024 |
| What is produced | A KYC-Security Attestation submitted in the KYC-SA application after an independent assessment | A Report on Compliance by a QSA, or a Self-Assessment Questionnaire, each with an Attestation of Compliance |
| Enforcement | Swift may report users without a valid attestation or not compliant with mandatory controls, visible to their supervisors | Payment brands decide which entities must validate and run any enforcement programs |
Which systems fall under the CSCF and which fall under PCI DSS
CSCF scope follows your Swift connection, and PCI DSS scope follows your cardholder data. The CSCF controls that apply to you depend on the architecture type under which you connect to Swift (A1, A2, A3, A4 or B), so the in-scope footprint is the Swift interface, the connected back office, and the infrastructure that supports them. PCI DSS scope starts from where cardholder data or sensitive authentication data is stored, processed or transmitted, and extends to any system that could affect the security of that cardholder data environment. A payment platform can therefore sit fully inside PCI DSS and outside the CSCF, or the reverse, and many systems sit in both. Confirm your Swift architecture type with your Swift administrator before you draw any boundary.
The overlap is usually in shared hosts, identity systems and administrators. A jump host, directory, privileged access tool or hypervisor that serves both a SWIFT Alliance environment and a card switch is in scope for both, and the controls on it must satisfy both assessors. Map each data flow end to end, record every connection type, and list the administrators and service accounts with access to each segment before assuming a system is out of scope for either. Ask your QSA and your CSCF assessor to review the same diagram so they agree on the boundary.
PCI DSS applies to merchants, processors, acquirers, issuers and service providers, so your card role decides whether it applies at all. A bank that only issues cards through a processor may have a different obligation from one that acquires merchant transactions or operates its own card processing. Confirm with the payment brands and your acquirer or processor which entities must validate and how, because the PCI SSC does not enforce compliance itself. Every bank connected to Swift must attest to the CSCF, so the card role changes the PCI DSS side of the scope, not the CSCF side.
Where CSCF and PCI DSS work overlaps
Swift defines each CSCF control in line with recognized standards, including PCI DSS, so several domains look familiar to a card-processing team. The overlap is in the control themes, not in the assessments, which test different scopes and reach different conclusions.
Credentials and privileged access
CSCF objective two covers limiting access, and PCI DSS covers account and privileged access for the cardholder data environment. Map one set of administrator accounts, service accounts and MFA settings to both. Check whether the Swift interface and the card platform share jump hosts, admin consoles or identity stores, because a shared control must be evidenced for each scope.
Penetration testing cadence
CSCF advisory control 7.3A (Penetration Testing) is optional, while PCI DSS requires internal (11.4.2) and external (11.4.3) penetration testing at least every 12 months and after significant infrastructure or application change. A PCI test may not cover the Swift footprint at all. Confirm whether the test scope names the Swift interface and whether results are usable for the attestation.
Intrusion detection
CSCF advisory control 6.5A (Intrusion Detection) is not mandatory, but many teams run intrusion detection for PCI DSS monitoring of the cardholder data environment anyway. Decide whether the Swift segment is inside that monitoring. If it is, one detection platform and one alert record can support both reviews. If it is not, document why and what covers the gap.
Secure configuration and hardening
Both frameworks expect systems to be configured against a documented baseline, with unnecessary services removed and default credentials changed. The Swift footprint often runs on separate operating systems and middleware from the card stack. Keep one hardening standard with per-system exceptions, and record which build covers the Swift connector and which covers the payment application.
Monitoring and log review
Both assessments look for evidence that security events are collected, reviewed and acted on. The CSCF focuses on detecting and responding to events affecting the Swift environment, while PCI DSS focuses on the cardholder data environment. A single log pipeline can serve both, but confirm that Swift-related sources are in the scope of the PCI review and that the assessor can see the review records.
Reusing SOC 2 evidence
A QSA cannot rely on a SOC 2 or SOC 3 report for PCI DSS, but may reuse evidence from those audits after independently reviewing it. This can reduce duplicated evidence work across the card and Swift programs. It does not transfer the CSCF attestation, which still needs its own independent assessment and KYC-SA submission. Ask the QSA early which evidence they will accept.
Who assesses each framework and what each assessment issues
This table sets out who performs each assessment, what document it produces and how often it recurs for CSCF and PCI DSS. Read it to see where the two obligations diverge in people and paperwork, and where a single evidence set can serve both.
| Element | SWIFT CSCF | PCI DSS |
|---|---|---|
| Who performs the assessment | Internal review by a second or third line function such as risk, compliance or internal audit, or an external independent assessor | A Qualified Security Assessor for a ROC, or the entity itself for an SAQ |
| Optional credential for the assessor | Swift's CSP Assessor Certification is optional, not required | QSA status is required for ROC work; SAQs need no assessor credential |
| Output document | KYC-Security Attestation submitted in the KYC-SA application | Report on Compliance or Self-Assessment Questionnaire, each with an Attestation of Compliance |
| Certificates accepted as proof | Not a certificate exercise; the attestation is the filed record | Not recognized; certificates are not validation under PCI SSC FAQ 1220 |
| Assessment cycle | Community Standard Assessment every year to support the annual KYC-SA | Annual validation on the official PCI SSC templates |
| Who sees a shortfall | Swift may report users without a valid attestation or not compliant with mandatory controls, visible to their supervisors | PCI SSC does not enforce; payment brands decide who must validate and run any enforcement |
| Reuse of SOC 2 evidence | A SOC 2 report supports the assessment but does not replace the Community Standard Assessment | A QSA may reuse SOC 2 evidence only after independently reviewing it |
| What to confirm with your assessor | Which assessor line applies to your Swift architecture type and how your evidence is retained | Whether your entity needs a ROC or an SAQ, and which payment brand rules apply to you |
How testing requirements and assessment cycles differ
The CSCF runs on an annual cycle tied to Swift's publication calendar. Swift publishes a new CSCF version every July, a year before it applies, and gives users up to 18 months to prepare for new or changed controls. CSCF v2026, published in July 2025, is the version users attest against between July and December 2026. Each year, the KYC-Security Attestation depends on an independent assessment, which may be internal (second or third line, such as risk, compliance or internal audit) or external. Your team should confirm which CSCF version applies to its next submission and which control changes fall into its preparation window, rather than assuming the prior year's controls still hold.
PCI DSS moves on a different clock. PCI DSS v4.0.1 is the only active version, published on 11 June 2024 as a limited revision with no added or deleted requirements. Of the 64 new requirements introduced in v4.0, 51 were future-dated and became effective on 31 March 2025, so any evidence gathered before that date may not meet today's expectations. Penetration testing under requirements 11.4.2 and 11.4.3 must run at least every 12 months and after significant infrastructure or application changes, which is a recurring obligation separate from the CSCF attestation cycle. The PCI SSC ran a request for comments from 3 June to 20 July 2026 to begin the next iteration, and as of October 2026 it had announced no release date. Ask your QSA which PCI DSS version the next ROC or SAQ will be assessed against.
Because both calendars can change, a rule change in either framework can shift the same evidence set. Penetration test records, change logs, access reviews and network segmentation tests may serve both a CSCF assessment and a PCI DSS assessment, but a revised requirement or control can alter what counts as sufficient. Build one register that maps each evidence item to the CSCF control and PCI DSS requirement it supports, with the version and test date recorded. Then set two review dates a year: one after the CSCF version is published, and one after any PCI SSC announcement on the next standard. This keeps both attestations defensible without running two separate evidence programs.
Which to do first and how to share evidence
This sequence fixes scope in writing, builds one evidence register that serves both the CSCF attestation and the PCI DSS assessment, and then runs each assessment on its own track so neither framework's proof is compromised by the other.
Confirm Swift architecture type and card role
Start by documenting how your institution connects to Swift, which determines the architecture type (A1, A2, A3, A4 or B) and therefore which CSCF controls are in scope. In the same exercise, record your role in card processing: whether you store, process or transmit cardholder data, act as a merchant, processor, acquirer, issuer or service provider, or could affect the cardholder data environment. Owners are the Swift operations lead and the card programme lead, with security sign-off. The step is done when both roles are written down with a named owner and a date, and the architecture type has been checked against the current Swift CSP controls guidance rather than memory.
Define and document both scopes in writing
Draw the CSCF scope (the Swift footprint, including systems, interfaces, operators and the connectivity architecture) and the PCI DSS scope (the cardholder data environment, connected-to and security-impacting systems). Then map where they overlap, such as shared jump hosts, identity directories, SIEM pipelines, network segments or administrators who touch both environments. Ask your QSA and your CSCF assessor to review the draft, because the PCI DSS scoping rules and the Swift architecture rules do not always draw the same boundary. The step closes when a signed scope statement exists for each framework and an overlap register lists every shared component with its owning team.
Build one control evidence register
Create a single register with one row per control or requirement that both frameworks touch, such as network segregation, access reviews, privileged access, vulnerability management, logging, incident response and penetration testing. Each row should name the CSCF control or PCI DSS requirement it satisfies, the system in scope, the evidence artefact, the evidence owner and the date collected. Because Swift defines its controls in line with recognized standards including PCI DSS, many rows will map to both. Treat the register as the source of truth and keep the assessor-specific packs as extracts from it. The step is complete when every in-scope control has at least one evidence item and every gap is logged with an owner.
Close gaps against mandatory and advisory controls
Review the register against the 26 mandatory CSCF v2026 controls first, since a missing mandatory control affects the KYC-SA attestation directly, and then against the six advisory controls, which should be implemented or formally assessed where your architecture makes them relevant. Check PCI DSS penetration testing and other periodic requirements in the same pass, so one test or review can produce evidence for both. Where a PCI DSS requirement is met through the customized approach or a compensating control, record the reasoning in the register with the approver. The step is done when remediation tickets exist for every gap and each open item shows a target owner, not a date you have not confirmed.
Book the CSCF independent assessment and PCI DSS validation separately
Run the two assessments on separate tracks because they answer different questions. For CSCF, your independent assessment can be internal (second or third line such as risk, compliance or internal audit) or external, and it supports the annual KYC-SA attestation. For PCI DSS, a QSA completes a ROC, or you complete an SAQ with its AOC, depending on your validation type. Confirm with each assessor which evidence they will accept, how they will sample, and whether they will rely on the shared register. Decide the order based on which deadline is nearer and which assessor is available, and fix that order in writing. The step closes when both engagements have a written scope and a named assessor.
Run assessments and reconcile findings
During fieldwork, give each assessor read-only access to the register and its underlying artefacts, and keep a log of every request and response. When one assessor raises a finding, check the register for the matching row and confirm whether the other framework is affected, for example a change to a shared jump host or a logging gap that touches both the CSCF logging control and a PCI DSS log review requirement. Do not let one assessor's sample override the other's conclusions without review. The step is done when each assessor has issued its output (an independent assessment result or a ROC or SAQ with AOC) and every finding has been reconciled in the register with its status recorded.
Submit attestations and maintain evidence through the annual cycle
Submit the KYC-Security Attestation in the Swift application and file the PCI DSS AOC with the entities that require it, keeping copies of both in the register. Remember that the CSCF version changes each July, so note the version you attested against, and that PCI DSS changes need to be tracked separately. Assign owners for recurring evidence such as quarterly access reviews, periodic penetration tests and change records, and set a review of the register after any significant infrastructure change, since PCI DSS requires penetration testing after such changes. The step closes when the attestation and AOC are filed, the register is versioned, and the next cycle's owners and collection dates are confirmed.
What do buyers ask before hiring help for CSCF and PCI DSS?
Can one assessment cover both SWIFT CSCF and PCI DSS?
No. The two frameworks produce different outputs and are assessed by different people, so one engagement cannot replace the other. The CSCF is attested annually through the KYC-Security Attestation, based on a Community Standard Assessment that may be internal, performed by a second or third line function, or external. PCI DSS is documented on a Report on Compliance completed by a Qualified Security Assessor, or on a Self-Assessment Questionnaire, each with an Attestation of Compliance. Evidence can be shared across both programs, and a QSA may reuse evidence from SOC 2 or SOC 3 reports after independently reviewing it, but each attestation still needs its own assessor sign-off and template.
What drives the cost and effort of CSCF and PCI DSS work?
The main drivers are scope and architecture. For CSCF, the number of Swift connections and the architecture type (A1, A2, A3, A4 or B) determine which of the 32 controls apply. For PCI DSS, the size and complexity of the cardholder data environment and the number of systems that could affect it drive the work. Evidence maturity matters in both: a team with current asset inventories, documented access reviews and retained logs spends less time rebuilding proof. Assessor type also changes the bill, since an internal CSCF assessment carries staff time, while a PCI DSS ROC requires a QSA. Ask any provider to price each program separately, with its assumptions listed.
How long does a CSCF and PCI DSS readiness project take?
Duration depends on the written scope and on how ready your environment already is, so no fixed timeline applies across institutions. Timing has its own anchors. CSCF v2026 was published by Swift in July 2025 and is the version users attest against between July and December 2026. Swift publishes each new version a year before it applies and gives users up to 18 months to prepare for new or changed controls. For PCI DSS, internal and external penetration tests must occur at least every 12 months and after significant changes. Ask the provider to show the milestones, dependencies and client review points in the scope before work starts.
What does the work need from our internal team?
Expect steady input from several roles rather than a single project owner. The usual contributors are:
- Swift operations staff who know the connection architecture and the BIC and interface footprint
- Infrastructure and security engineers who can confirm hardening, segregation and logging settings
- Identity and access administrators who own privileged accounts and periodic reviews
- Card operations and network teams who can define the cardholder data environment
- Risk, compliance or internal audit staff who will perform or review the independent assessment
Each group should name a reviewer with authority to accept evidence, because gaps often stall at sign-off rather than at technical work.
Can our team run the CSCF and PCI DSS work without an outside firm?
Partly, and the rules differ by program. The CSCF independent assessment may be internal, carried out by a second or third line function such as risk, compliance or internal audit, or external, and Swift's CSP Assessor Certification is optional. PCI DSS allows a Self-Assessment Questionnaire to be completed by the entity, with its Attestation of Compliance, but a Report on Compliance must be completed by a Qualified Security Assessor. Internal teams should also check whether their program sits within the chosen SAQ type, because the questionnaire type depends on how cardholder data is handled. Independence of the assessor from the implementation work is a judgment your auditors and assessors will make, so confirm that position early.
What should a quote for CSCF and PCI DSS work include?
A useful quote lists the scope in writing, with each program treated separately. Ask for the list of CSCF controls in scope for each architecture type and connection, and the systems and networks counted in the PCI DSS scope. Require deliverables, such as gap analysis, remediation support, evidence packs, and the documents the assessor will review. Ask which items are one-time and which recur, such as the annual CSCF cycle, the 12-month penetration testing cadence, and the PCI DSS validation each year. Confirm what the quote excludes, including the assessor fees you pay directly, tooling and any retesting. Ask how changes in scope or new CSCF and PCI DSS versions would be priced. DeployOpen works from a written, fixed scope and does not publish a price list, so a quote follows from that scope.
Which assessment outputs will our regulators or card brands see?
Swift may report users without a valid attestation or who are not compliant with mandatory controls, and that lack of compliance is visible to their supervisors. PCI DSS attestations are presented to the entity's acquirer or payment brands, and the PCI Security Standards Council does not enforce compliance itself. The individual payment brands decide which entities must validate and run any enforcement programs. Before scoping, confirm with your acquirer and the relevant brands which validation level and SAQ or ROC type applies to your organization, because that answer changes the assessor requirement and the evidence you need to keep.
What drives the cost of doing both
Doing both programs means paying for two assurance cycles that look at overlapping systems on different schedules. Your own staff carry most of the internal cost: the people who own the Swift interface and its access model, the people who own cardholder data environment (CDE) segmentation and network documentation, and the people who gather evidence for each assessor. External spend has two main lines. For the CSCF, the independent assessment may be internal (by a second or third line function such as risk, compliance or internal audit) or external, and Swift's CSP Assessor Certification is optional, so ask whether your assessor holds it. For PCI DSS, a Qualified Security Assessor completes the ROC or the SAQ requires your own completion, and the QSA's fee is a separate line from anything the CSCF costs you. Remediation is the third line and is the least predictable: a gap in the CSCF and a gap in PCI DSS may share a root cause, such as a flat administrative network that touches both the Swift interface and the CDE.
One-time costs sit mainly in the first cycle: defining the scope of each program, building the network segmentation and privileged access controls both require, and closing gaps found in a baseline assessment. Scope definition is the largest single lever. If the CSCF architecture type for your Swift connection and the PCI DSS scope of your CDE are drawn separately, you pay twice to rediscover the same systems. Recurring costs include the annual CSCF attestation and independent assessment, the annual PCI DSS validation, penetration testing at least once every 12 months as PCI DSS v4.x requires for SAQ D and ROC work, and the evidence collection that keeps both sets current. Version changes add a further recurring line. CSCF v2026 applies to attestations filed between July and December 2026, and the next CSCF version is published each July, with up to 18 months to prepare for new controls. PCI DSS v4.0.1 is the only active version, and the PCI SSC opened a request for comments in June and July 2026 on the next iteration, with no release date announced as of October 2026. Budget for a change review each cycle, not only when a version becomes effective.
When you request quotes, ask for a written scope with separate line items for the CSCF assessment, the PCI DSS ROC or SAQ work, remediation estimates, tooling and any retained support. Ask each provider to state which systems and controls are in its scope, which evidence it will reuse from the other program, and how it will handle a PCI DSS requirement that the CSCF does not address, and the reverse. Ask whether the price covers one cycle or recurring years, and what triggers a re-quote when CSCF or PCI DSS changes. DeployOpen does not publish a price list. A quote follows from a written scope agreed before work starts, so the line items above are the basis for comparing any proposal, including ours.
What changes if the card or Swift footprint changes later
This sequence shows how a change in card processing or Swift connectivity reopens the affected assessment, and how a single evidence register keeps the rework limited to the controls and requirements that actually moved.
Log the scope change before it goes live
The team that owns the change, usually the platform or payments lead with compliance, records what is changing: a new Swift connection type, a new card flow, a new processor, or a different PCI DSS validation route. The record names the systems, data flows and people affected. Done means the change ticket links to a scope note that both the CSCF and PCI DSS owners have read and signed. Ask your assessors early which parts of the change they will treat as in scope, because the answer differs by framework.
Re-map the Swift architecture type
The Swift security officer checks whether the change moves the institution to a different connection architecture among the five types in CSCF v2026 (A1, A2, A3, A4 and B). The architecture type decides which controls apply, so a change in connectivity can add or remove controls even when no card data is involved. Done means a written architecture determination exists for the affected Swift footprint. Confirm the current determination against the Swift CSP Understand controls guidance rather than relying on last year's record.
Re-map the cardholder data environment
The payments or compliance lead redraws the cardholder data environment, including any system that stores, processes or transmits cardholder data or could affect its security. If card processing moves to a service provider, the team also collects that provider's responsibility matrix and current validation evidence. Done means the updated data flow diagram is approved and the list of in-scope systems matches it. Outsourcing does not remove the institution's responsibility, so the review must show who performs each requirement.
Reassess the controls the change touches
The affected assessor re-tests the controls that changed scope. For CSCF, the Community Standard Assessment is repeated for the controls tied to the new architecture type, and the independent assessor decides whether a new internal or external review is needed. For PCI DSS, the QSA or internal assessor re-tests the requirements for any new or changed system in the cardholder data environment, including penetration testing after significant changes. Done means each assessor has written results for the changed scope, not a general statement that the program still holds.
Update the shared evidence register
The compliance lead updates the single evidence register that both frameworks draw on. Each control or requirement entry links to its evidence, owner, test date and the systems it covers, and the register flags entries that the change invalidated. Evidence that depends only on unchanged systems, such as policy approvals or staff screening records, stays valid and is not collected again. Done means every flagged entry is either re-evidenced or marked as not affected with a reason recorded.
Confirm the PCI DSS validation route
The compliance lead confirms whether the change alters the PCI DSS validation level or the route the institution follows, such as a move between a ROC and an SAQ, or a change in how a requirement is met. Where a requirement is met through a customized approach rather than the defined approach, that change must be re-documented and reviewed. Done means the validation type, the Attestation of Compliance and the assessor's scope statement all match the new environment. Confirm the applicable route with your acquirer or the payment brands, since the PCI SSC does not enforce compliance itself.
Refresh the attestations and keep the record
The compliance lead prepares the updated Swift attestation for the next KYC-Security Attestation cycle and, where required, the current PCI DSS Attestation of Compliance. Each document must describe the scope as it stands after the change, and the record must show the date of each reassessment. Done means both attestations reference the same architecture and cardholder data environment descriptions, and the change ticket closes with a link to the revised register. Ask your assessor to confirm in writing that the shared evidence was reviewed for each framework.
How DeployOpen prepares evidence for both frameworks
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and prepares systems, controls and evidence for compliance assessments. We do not issue attestations, reports or certifications, so the Swift attestation, the independent assessment and the PCI DSS Qualified Security Assessor or SAQ work remain with the parties that perform them.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope lists which CSCF architecture type applies and which Swift-connected systems fall inside it.
- The scope also names the cardholder data environment systems and the shared components both frameworks touch.
How we build
- Controls are implemented against the CSCF v2026 control set and the PCI DSS v4.0.1 requirements, mapped in one control register.
- Hardening, access, logging and segmentation work is configured once and documented against both sets of control IDs.
- Penetration testing is scheduled so one test run can produce evidence for the CSCF and PCI DSS testing requirements.
How we hand over
- Deliverables include the control register, configuration records, test results and the evidence index for each framework.
- Documentation is written so the independent assessor and the QSA can each trace a control to its source evidence.
- Evidence that a SOC 2 report or other audit already covers is listed with its review notes, so the QSA can decide on reuse.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, which can follow the annual CSCF and PCI DSS cycles.
- Support covers updating the control register when Swift publishes a new CSCF version or PCI DSS changes.
- Ask each assessor, in writing, which evidence formats and sampling approach they accept before the evidence set is finalized.
