How often does each framework need an audit or assessment?
If you are building one compliance calendar for several obligations, start by sorting each framework into the type of proof it produces, because that determines the rhythm. A SOC 2 report has no fixed cycle: a Type 1 report covers the system description and control design as of a date, while a Type 2 report covers operating effectiveness over a period. The period length is set by what the service auditor needs to opine on, and there is no generally accepted minimum, so confirm the window with your CPA firm before you schedule it. For ISO/IEC 27001, the certification cycle runs three years, with at least one audit in every calendar year under ISO/IEC 17021-1, which means a surveillance or recertification audit must fall in each of those years. Accredited certification bodies run these audits, not DeployOpen.
Several assessments recur annually or on shorter clocks. Under Visa's rules, Level 1 merchants and Level 1 service providers file an annual PCI DSS Report on Compliance completed by a QSA, while Level 2 and 3 merchants and Level 2 service providers file an annual Self-Assessment Questionnaire. For CMMC Level 2, a new assessment is due every three years, and a senior Affirming Official must affirm continuing compliance in SPRS after the assessment and then annually; the assessment lapses if the annual affirmation is missed. HITRUST e1 and i1 certifications are valid for one year, r2 certifications for two years with an interim assessment due in the 90 days before the first anniversary. The Swift Community Standard Assessment is required every year to support the KYC-Security Attestation.
Other regimes set cycles by role or by regulator decision. Under the NERC Rules of Procedure, Balancing Authorities, Reliability Coordinators and Transmission Operators receive a Compliance Audit at least once every three years, while other registered entities follow a risk-based schedule set by the Regional Entity. Under DORA, financial entities identified by their competent authority must run threat-led penetration testing at least every three years, and the authority can ask for more or less frequent testing based on risk. The GDPR, NIS2 and HIPAA have no fixed audit cycle or certificate, so for those obligations the calendar is driven by your regulator, your customers and your own risk profile. Confirm with your registration authority, level assignment or regulator which cycle applies to your entity. DeployOpen plans and prepares the systems, controls and evidence for these assessments, but it does not issue audit reports or certifications.
Assessment cycles side by side for SOC 2, ISO 27001, PCI DSS, CMMC, HITRUST, Swift, NERC CIP and DORA
This table sets each framework's assessment cycle, assessor and recurring obligation against the proof it produces, so you can build one compliance calendar. Where the period is set by an auditor or regulator rather than a fixed number, the cell says so and names what to confirm.
| Framework and scope | Who assesses and cycle | What recurs | Proof produced and what to confirm |
|---|---|---|---|
| SOC 2 Type 1 | CPA service auditor. Point-in-time report as of a date, no fixed cycle set in the standard. | Usually repeated on your own schedule, not mandated by a fixed interval. | CPA examination report on system description and control design. Confirm the report date and who may receive it, since SOC 2 use is generally restricted. |
| SOC 2 Type 2 | CPA service auditor. Observation period set by the auditor; no generally accepted minimum period. | Period should be long enough for the auditor to opine on operating effectiveness. Confirm the period length with your auditor before fieldwork. | CPA opinion on operating effectiveness over the period. Confirm whether you need a SOC 3 general use report as well. |
| ISO/IEC 27001 | Accredited certification body. Three-year certification cycle. | At least one audit (surveillance or recertification) in every calendar year. | Certificate from an accredited body. Confirm the certification body is accredited and that it applies ISO/IEC 27006-1:2024 to your audits. |
| PCI DSS | Qualified Security Assessor (ROC) or self-assessment (SAQ), per Visa's level rules. | Annual ROC for Level 1 merchants and Level 1 service providers; annual SAQ for Level 2 and 3 merchants and Level 2 service providers. | Report on Compliance or SAQ, each with an Attestation of Compliance. Certificates are not recognized as validation. Confirm your level with your acquirer or payment brand. |
| CMMC Level 2 | Self or C3PAO assessment; C3PAOs are authorized or accredited by The Cyber AB. | New assessment every three years, plus senior Affirming Official affirmation in SPRS after each assessment and annually after that. | Assessment result and SPRS affirmation. The assessment lapses if the annual affirmation is not made. Confirm the affirmation calendar with your contracting officer. |
| CMMC Level 3 | DCMA DIBCAC performs the certification assessment. | Assessment cadence set by the CMMC rule and DIBCAC scheduling. Confirm current timing with DIBCAC before planning. | Certification assessment outcome recorded in SPRS. Confirm whether Level 3 applies to your contracts before scheduling. |
| HITRUST e1 and i1 | Accredited HITRUST assessor under the HITRUST Assessment Handbook. | Certification valid for one year, so reassessment is due annually. | HITRUST certification. Confirm the assessor is authorized and the scope matches the systems your customers care about. |
| HITRUST r2 | Accredited HITRUST assessor under the HITRUST Assessment Handbook. | Certification valid for two years, with an interim assessment due in the 90 days before the first anniversary. | HITRUST certification. Confirm the interim assessment date in your project plan so the certification does not lapse. |
| Swift CSCF (Customer Security Programme) | Community Standard Assessment under Swift's Independent Assessment Framework, with the KYC-Security Attestation submitted to Swift. | Every Swift user must complete a Community Standard Assessment each year. | Annual KYC-Security Attestation supported by the assessment. Confirm your attestation deadline and whether an independent assessor is required for your user type. |
| NERC CIP | NERC Regional Entity compliance audit. Balancing Authorities, Reliability Coordinators and Transmission Operators are audited at least once every three years. | Other registered entities are audited on a risk-based schedule set by the Regional Entity. | Regulator audit findings and enforcement outcomes. Confirm your registration category and your Regional Entity's audit schedule. |
| DORA threat-led penetration testing (TLPT) | Testers chosen under the regulation and supervised by the competent authority. Authority may set more or less frequent testing. | At least every three years for entities identified by their competent authority; frequency depends on risk profile. | Attestation that the TLPT met the requirements (Article 26(7)). Confirm the interval with your competent authority, since it can differ from three years. |
What changes your assessment calendar in practice
Assessment dates rarely depend on the framework alone. The scope of the system, the level or category your organization falls into, and the evidence you can reuse all move the calendar, so check these before you fix a schedule.
Scope of the cardholder data environment
The PCI DSS assessment covers every system that stores, processes or transmits cardholder data, and every system that could affect its security. A system you bring into that boundary during the year can pull it into the current assessment, while removing one may shrink the work. Map the cardholder data environment and its connected systems before you set the assessment window, and confirm the boundary with your QSA or the acquirer before you commit to a date.
Merchant or provider level under Visa
Visa's requirement for an annual ROC or an annual SAQ depends on your merchant or service provider level. Level 1 merchants and Level 1 service providers need an annual ROC from a QSA, while Level 2 and 3 merchants and Level 2 service providers complete an annual SAQ. Your level can change with transaction volume, so review it each year and confirm the current classification with your acquirer or Visa before you book a QSA.
NERC registered category
Balancing Authorities, Reliability Coordinators and Transmission Operators receive a Compliance Audit at least once every three years under Section 403.10.1 of the NERC Rules of Procedure. Other registered entities are audited on a risk-based schedule set by the Regional Entity. Confirm your registration functions with your Regional Entity, because the registration determines whether you are on a fixed three-year cycle or a schedule you need to ask about.
SOC 2 Type 2 observation period
A SOC 2 Type 2 report opines on operating effectiveness over a period, and no generally accepted minimum period exists. The period must be long enough for the service auditor to form that opinion. Choose the window with your auditor, align it with your release and change cycles, and avoid starting it just before a major system change that would split the evidence.
ISO certificate in recertification
An ISO/IEC 27001 certification runs on a three-year cycle, with at least one audit in every calendar year, either surveillance or recertification. A new certificate and a recertification therefore place audits in different years of the same cycle. Confirm with your certification body which year is the recertification year, and check that the certificate is issued under the transition rules that apply to your certification body.
Reusing existing evidence
A QSA cannot rely on a SOC 2 or SOC 3 report for a PCI DSS assessment, but may reuse evidence from those audits after independently reviewing it. Reuse can reduce duplicated evidence work, yet the review still takes time and the timing of the SOC 2 period must line up with the PCI DSS assessment. Ask your QSA which evidence they will accept and when they need it before you plan the calendar around a shared audit.
How the SOC 2 report period shapes your calendar
The report period decides how long your SOC 2 evidence has to stay clean, so it is the first calendar decision to settle. A Type 1 report describes your system and tests whether controls were suitably designed as of a single date. A Type 2 report adds an opinion on whether those controls operated effectively over a period of time. Readers planning a first attestation should expect a Type 1 to be a point-in-time milestone and a Type 2 to be a multi-month observation window that starts on the first day of the period and ends on its last. No generally accepted minimum length exists for a Type 2 period. The test is whether the period is long enough for the service auditor to form an opinion on operating effectiveness, and that judgment is made for your specific controls and population. Ask your CPA to state the proposed period in writing before fieldwork begins, and ask what sample sizes and evidence dates they expect to test across it. Controls that run quarterly, such as access reviews, need enough occurrences inside the period to be tested at all.
SOC 2 is an *assertion-based* examination under AT-C section 205 of the AICPA attestation standards. That means management must make written representations about its system and controls, and the service auditor relies on them. Ask your CPA which management representation letter template the engagement will use and who at your organization signs it, because that signer is accountable for the statements in the period. The AICPA Auditing Standards Board exposed proposed revisions to its baseline attestation standards in February 2026. If adopted, they would apply to engagements beginning on or after June 15, 2029. Confirm with your CPA whether any proposed change would alter how your next period is scoped or evidenced, and plan a conversation about it before your calendar locks.
How to confirm each cycle in your own environment
This sequence turns the assessment cycles in this comparison into a dated compliance calendar that names who sets each obligation and which evidence serves more than one audit. Each step ends with a written confirmation you can file.
List every obligation and its registering authority
Start by writing down every framework, regulation or contractual certification that applies to your organization, and the body that sets or checks it. Legal or compliance leads should confirm applicability with counsel, and the list should separate bodies that certify, bodies that attest through a CPA or assessor, and regulators that supervise without issuing a certificate. Close the step with a single register that shows, for each line, the assessment type, the report or certificate produced and the owner. Done means every line has a named owner and a named authority.
Confirm your Visa merchant or service provider level
If you accept or process card payments, confirm your Visa level with your acquirer or with Visa directly, using Visa's published compliance validation page as the starting reference. Visa requires an annual ROC by a QSA for Level 1 merchants and Level 1 service providers, and an annual SAQ for Level 2 and 3 merchants and Level 2 service providers. Ask your acquirer in writing which level it has recorded for you and which validation it expects, because the payment brands, not the PCI SSC, set those requirements. Done means you hold a written level and a matching validation type on your calendar.
Confirm your NERC registration category
If you operate in the North American bulk electric system, confirm with your Regional Entity which NERC registration categories you hold. Entities registered as a Balancing Authority, Reliability Coordinator or Transmission Operator receive a Compliance Audit at least once every three years under Section 403.10.1 of the NERC Rules of Procedure. Other registered entities are audited on a risk-based schedule set by the Regional Entity, so ask for that schedule in writing and the date of your last audit. Done means you have the registration category, the audit cycle that applies and the next audit window on record.
Confirm the HITRUST certification type customers require
Ask each customer or partner that cites HITRUST which certification type they require, since e1 and i1 certifications are valid for one year and r2 certifications are valid for two years with an interim assessment. For r2, mark the interim assessment window in the 90 days before the first anniversary, as the HITRUST Assessment Handbook describes. Confirm the certification body's status through HITRUST's own listing before you rely on it. Done means each customer requirement is tied to one certification type and its expiry and interim dates.
Confirm with the CMMC assessor whether Level 2 is self or C3PAO
If you handle controlled unclassified information for a Department of Defense contract, confirm with your contracting officer and your assessment provider whether your Level 2 assessment is self-assessment or a C3PAO assessment, because the requirement depends on the contract and the CUI involved. Under 32 CFR 170.16 and 170.17, a new Level 2 assessment is due every three years. Under 32 CFR 170.22, a senior Affirming Official must affirm continuing compliance in SPRS after the assessment and annually after that, and the assessment lapses if the annual affirmation is not made. Done means your Affirming Official, affirmation dates and assessment type are written into the calendar.
Map shared evidence across regimes
Build a control-to-evidence map that shows which artifacts answer more than one audit, such as access reviews, change records, log samples and vulnerability scan results. The CIS Controls Navigator and NIST's CSF 2.0 reference materials publish mappings to several frameworks, which you can use as a starting point, but NIST does not verify non-NIST mappings and ENISA states its mapping is not a measure of equivalence. Under PCI DSS, a QSA may reuse evidence from a SOC 2 or SOC 3 audit only after independently reviewing it, so confirm that reuse with your QSA before you rely on it. Done means each shared artifact has an owner, a refresh date and a list of the audits it supports.
Set dates for affirmations, interim assessments and surveillance audits
Enter every recurring date into one calendar: SOC 2 report periods, the ISO certification surveillance audits (with at least one audit each calendar year within a three-year cycle), the annual PCI DSS validation, the CMMC annual affirmation, HITRUST interim assessments, the annual Swift Community Standard Assessment, NERC audit windows and the DORA threat-led test cycle set by your competent authority. Confirm each date with the assessor or authority in writing and assign an owner who receives reminders. Done means the calendar lists every obligation with its next due date, its evidence owner and its confirmation source.
Questions buyers ask about audit frequency and cost
How much recurring effort does a compliance audit cycle actually need?
The effort depends on the framework's cycle and on how much evidence your team already produces. An annual assessment, such as a PCI DSS ROC or SAQ, recurs every year, while an ISO 27001 certification runs on a three-year cycle with at least one audit in every calendar year under ISO/IEC 17021-1. Between formal assessments, you still carry ongoing work: maintaining control records, reviewing access, tracking changes and closing findings. The recurring effort is usually the evidence collection and remediation loop, not the external assessment itself. Ask any provider to split the estimate into preparation, fieldwork support, remediation and evidence upkeep, and to state which of these recur each cycle.
Who pays for what in a recurring assessment?
Three parties usually carry cost: the assessor, the internal team and any implementation partner. The assessor (a QSA for PCI DSS, a C3PAO for CMMC Level 2, a CPA for SOC 2, or an accredited certification body for ISO 27001) charges for the examination itself. Your internal staff pay in time for system owners, evidence requests and interviews. An implementation partner such as DeployOpen is paid under a written scope for preparation, remediation, testing or documentation work that you choose to buy. DeployOpen does not issue audit reports, attestations or certifications, so assessor fees and partner fees should appear as separate line items in any quote you compare.
Can our team run the audit calendar without outside help?
Many organizations run the calendar internally, provided someone owns it and the due dates are tracked. Some deadlines are fixed by rule, such as the three-year Level 2 CMMC reassessment and the annual senior affirmation in SPRS, and an assessment lapses if the annual affirmation is missed. A small team usually needs a named compliance owner, a control and evidence register, and a dated list of assessor bookings and interim checkpoints. Outside help is most useful for gap analysis, first-time readiness and remediation when internal staff lack time or experience with the framework. Confirm internally whether your team can meet each date, and confirm with your assessor which parts of the work they will not perform for you.
What do internal owners need to provide during each assessment?
Internal owners must supply accurate system descriptions, current control evidence and access to the people who operate those controls. For a SOC 2 Type 2 report, the service auditor needs management's written representations and evidence covering the whole examination period, so owners must keep records consistently throughout that period, not just at the end. For PCI DSS, owners must confirm scope, including every system that stores, processes or transmits cardholder data or could affect that environment. Plan named owners for each control area, a single point of contact for evidence requests, and a rule that evidence is dated and retained as it is produced. Ask your assessor for a written list of required evidence before fieldwork begins.
Can one evidence set serve several audits at once?
Partly, and the overlap depends on how the frameworks are mapped and how each assessor accepts reused evidence. PCI SSC FAQ 1567 states that a QSA cannot rely on SOC 2 or SOC 3 reports for a PCI DSS assessment, but may reuse evidence from those audits after independently reviewing it, which can reduce duplicated evidence work. The CIS Controls Navigator for v8.1 publishes CIS mappings to frameworks including SOC 2, PCI DSS v4.0, CMMC v2.0, DORA and NIS2, and NIST publishes informative references, but NIST states it does not check the correctness of non-NIST mappings. Treat published mappings as a starting point, then confirm with each assessor which evidence they will accept and in what form.
What drives assessment and implementation cost up or down, and what should a written quote include?
The main drivers are the number of systems and locations in scope, the number of frameworks assessed in the same period, the maturity of existing controls, how much evidence is already automated, and how many remediation cycles are needed. A quote should list:
- Scope: systems, sites, data types and framework versions covered
- Deliverables: named documents, control evidence and test results
- Timeline: milestones and dependencies on your team and your assessor
- Assumptions: what you provide, and what happens if scope changes
- Separate fees for assessor work, internal effort and partner work
DeployOpen does not publish a price list, and a quote follows from the written scope. Ask every provider for the same scope statement so the figures are comparable.
Where no fixed audit cycle exists
Several major regimes set no assessment calendar at all, so the cycle has to come from your own plan. GDPR requires no audit, attestation or certificate. Article 42 certification is voluntary, is issued for at most three years by an accredited certification body or supervisory authority, and does not reduce the controller's or processor's responsibility for compliance. NIS2 creates no certificate of compliance either. National competent authorities oversee it through inspections, security audits, security scans, information requests and administrative fines, and they decide when to use them. HHS states that no Security Rule standard requires an entity to certify compliance and that it does not endorse or recognize private certifications, so there is no HIPAA certification to renew. The NIST CSF is a voluntary outcome framework, and NIST states it does not offer certifications or endorsements of CSF-related implementations or services.
Because no regulator or program sets a date, the reader must set one. Decide which internal reviews will run each year, who owns them, and what evidence each review produces, such as a control walkthrough, a risk register update or a documented GDPR Article 32 review of security measures. Confirm with your supervisory authority or national competent authority whether it expects any periodic information or registration, since that is set by national law and guidance, not by the frameworks themselves. Do not treat a voluntary certification as a substitute for these reviews, because the GDPR states it does not reduce your responsibility.
Customers will still ask for evidence on their own schedule, often during onboarding or contract renewal. Build a standing evidence pack that can be produced on request: current policies, a data processing description, a recent penetration test summary, and a list of any independent reports you hold, with their period and scope. Ask each customer which document they accept as proof, because some will require a SOC 2 report or an ISO certificate even where the underlying law requires neither.
Calendar priorities by team type
A payments team's calendar is driven first by its position in the card ecosystem. PCI DSS is assessed every year, but the form of that assessment depends on the entity's validation level, which the payment brands set. Visa requires an annual Report on Compliance from a Qualified Security Assessor for Level 1 merchants and Level 1 service providers, and an annual Self-Assessment Questionnaire for Level 2 and 3 merchants and Level 2 service providers. Most of the calendar is therefore annual, with the assessment date set by the attestation cycle rather than by a fixed audit window.
- Annual validation: PCI DSS is validated every year under the form the brands assign, either a ROC or an SAQ, each closed with an Attestation of Compliance.
- Standard version: PCI DSS v4.0.1 is the only active version, so plan the calendar against it and watch the request for comments on the next iteration.
- Overlapping 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 review, which can shorten evidence collection if both calendars are aligned.
- Service provider duties: Service providers should expect customers to request the current attestation on a yearly rhythm.
- Ownership of the date: The payment brands, not the council, set which entities validate and when.
Confirm your validation level and the exact form each acquirer or brand requires before fixing the calendar date.
A financial institution connected to Swift and subject to DORA runs two cycles that do not share a rhythm. Swift's Independent Assessment Framework requires every Swift user to undergo a Community Standard Assessment each year to support its KYC-Security Attestation. DORA has no certificate, but competent authorities can require threat-led penetration testing, which must be carried out at least every three years for entities the authority identifies, and the authority may ask for more or less frequent testing based on risk profile.
- Annual Swift cycle: The Community Standard Assessment and KYC-Security Attestation recur every year, so the Swift date should be fixed first.
- Three-year TLPT floor: Threat-led testing is at least every three years for identified financial entities, but the competent authority sets whether the interval is shorter.
- Authority-defined frequency: Ask the supervisor whether your risk profile moves the testing interval in either direction.
- Attestation from testing: Article 26(7) of DORA provides for an authority-issued attestation that a threat-led test met requirements, which is the only such attestation in the Regulation.
- Supervision, not certification: Ongoing DORA compliance is checked through supervision rather than a recurring certificate, so the calendar is set by the authority.
Confirm with your competent authority whether you are identified for TLPT and what interval applies, and confirm the current Swift assessment window with Swift.
A utility registered with NERC is audited through the Compliance Monitoring Program, and the cycle depends on the functional registration. Under Section 403.10.1 of the NERC Rules of Procedure, entities registered as a Balancing Authority, Reliability Coordinator or Transmission Operator receive a Compliance Audit at least once every three years. Other registered entities are audited on a risk-based schedule set by the Regional Entity. The registration type therefore decides whether the calendar has a fixed three-year anchor or a schedule your Regional Entity sets.
- Registration first: Confirm whether your functional registration is one of the three named in the rule, which sets the three-year maximum interval.
- Risk-based schedule: Other registered entities should ask their Regional Entity for the audit window and the factors it uses.
- Audit preparation: Plan evidence collection for the audit year, since the audit calendar sets the evidence deadline rather than a fixed annual attestation.
- Regional Entity contact: Schedules and scope notices come through the Regional Entity, so keep the contact current.
- Rule version: Check the current Rules of Procedure, since the section numbers and terms are set by NERC and can change.
Confirm your registration category and the current audit schedule with your Regional Entity before committing staff time.
A SaaS vendor selling to regulated buyers usually chooses its calendar around one or two reports its customers ask for. A SOC 2 Type 1 report covers the system description and the suitability of control design as of a date, while a Type 2 report adds an opinion on operating effectiveness over a period. The AICPA does not set a minimum Type 2 period, so the period should be long enough for the service auditor to opine on operating effectiveness, and that choice drives the report calendar. ISO/IEC 27001 certification adds a separate three-year cycle with yearly audits.
- Report period: A Type 2 period is set with the service auditor, and buyers often compare the period end date with their own renewal dates.
- Type 1 before Type 2: Some vendors start with a Type 1 report as a milestone, but confirm buyers will accept it before relying on it.
- Certification cycle: Under ISO/IEC 17021-1, certification runs three years with at least one audit in every calendar year, so ISO adds a yearly audit date.
- Restricted versus general use: A SOC 2 report is generally restricted, while a SOC 3 report is a general use report that can be freely distributed.
- Customer-driven demands: Buyers in regulated sectors may ask for PCI DSS or sector evidence on their own yearly schedule.
Confirm with your largest regulated customers which report, period and certification they expect, and map those dates to one shared calendar.
How DeployOpen helps plan and prepare for assessments
DeployOpen plans, implements and documents self-hosted platforms inside your own infrastructure, and prepares the systems, controls and evidence that assessors and auditors review. We do not issue audit reports, attestations or certifications, so the assessment calendar above stays with your independent auditor, certification body or assessor.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope lists which frameworks, systems and assessment periods the work supports, so the calendar is agreed up front.
- Confirm with your auditor which assessment type and period each framework needs before scope is signed.
How we build
- Controls and evidence collection are configured in the self-hosted platforms within your cloud accounts, data centers or air-gapped networks.
- Evidence routines are set up to produce records for each assessment window, such as access reviews and change records.
- Security testing is scheduled where your framework requires it, using the test types and dates agreed in the scope.
How we hand over
- Deliverables include documentation of controls, evidence locations and the recurring tasks needed for each assessment cycle.
- A written handover explains which tasks recur annually, every three years or on a fixed period, and who owns each one.
- Your team receives the calendar and runbooks, so future assessment cycles can be run without rebuilding the evidence trail.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, separate from the initial fixed-scope work.
- A retainer can cover recurring evidence checks ahead of each assessment window, agreed in writing.
- Confirm with DeployOpen what a retainer includes, response expectations and how it aligns with your assessor's dates before you commit.
Sources and further reading
- eCFR: 32 CFR Part 170 ↗
- Regulation (EU) 2022/2554 (DORA), EUR-Lex ↗
- NERC Rules of Procedure (Section 400, compliance monitoring) ↗
- IAF MD 29:2024 Transition requirements for ISO/IEC 27006-1:2024 ↗
- AICPA SOC 2: SOC for Service Organizations, Trust Services Criteria ↗
- Swift CSP: Perform an independent assessment ↗
