Compliance Frameworks and Certification Standards Questions

Direct answer

Both are SOC 2 (System and Organization Controls 2) reports: an independent CPA firm (a licensed accounting firm) examines your controls against the AICPA Trust Services Criteria and issues an opinion. The criteria are the AICPA's published control requirements, grouped into Security (always included) and optional categories such as Availability and Confidentiality; for example, a Security criterion expects that access to systems is restricted to authorized people. A Type I report says your controls were suitably designed at one point in time. A Type II report says they were designed and operated effectively over a period. Enterprise customers prefer Type II because it shows the controls actually ran. A young company should usually start the Type II observation window (the period the auditor tests, set out below) as early as it can, and use a Type I only as a bridge when a deal cannot wait.

What each tells the customer

Operating effectiveness, and why evidence spans the window

Operating effectiveness means the control worked consistently in practice, not just on paper. The auditor picks samples (a selection of real instances, such as a few tickets or a few months of logs, instead of every one) from across the whole observation window (the stretch of time the report covers; commonly three to twelve months, with a first report often covering three to six, and the length agreed with your auditor). A quarterly access review done once in the final week does not prove it ran in each quarter. Typical operational controls examined: user access provisioning and removal, change management (peer-reviewed, approved deployments), vulnerability management, backups, incident response and vendor management.

Worked example: new-hire access

Type I: the auditor reads the onboarding procedure and sees that access requires a manager-approved ticket. Type II: over a six-month window the auditor pulls several new hires from different months and checks that each had an approved ticket before access was granted. One hire with no ticket is an exception (a test result where the control did not work as described, which the report discloses). Illustrative sizing: with 24 hires in the window, an auditor might test 5 or so; the sample size is the auditor's call and grows with how often the control runs.

Which to pursue first

Recommendation: if the deal can wait a few months, skip Type I and start the Type II window once controls are stable, because most enterprise buyers will ask for Type II anyway and a Type I can cost an extra audit. If a customer needs something now, ask whether they accept a Type I plus a commitment date for Type II. Window length is chosen with your auditor; confirm what your target customers accept. What flips the call: a customer who accepts only Type II (then there is no shortcut), or a controls set still changing weekly (then fix it before any report, because exceptions in a Type II are disclosed to every customer and prospect who receives the report (SOC 2 reports are restricted-use documents, usually shared under an NDA, not public)).

Pitfalls

• SOC 2 is an attestation report (a CPA firm's signed opinion on your controls), not a certification.
• Reports describe what you scoped, so read the scope and the listed exceptions, not just the cover letter.

Direct answer

"Compliance" is several different obligations. For this company, only some are actually required, and the source of each obligation differs: a law (a regulator or government imposes it, with legal penalties), a contract (a counterparty imposes it, with contractual consequences), or voluntary (nobody requires it, but customers expect it).

For contrast, laws such as GDPR (EU privacy law) or HIPAA (US health privacy) are imposed by regulators, with enforcement action; the company is obliged only if its data and customers fall within them, and counsel decides.

Which of these is the company obliged to do?

PCI DSS if it takes card payments, FedRAMP only if it sells cloud services to US federal agencies, and nothing for SOC 2 or ISO 27001 unless a customer contract says so.

Why take on one nobody requires

SOC 2 or ISO 27001 replaces many separate customer security questionnaires with one independent report, unlocks enterprise deals, and forces a structured program. The cost is audit effort and ongoing upkeep, so choose by what customers demand.

Practical view for an analyst

Build one control set and map it to each obligation, because the same controls serve several. Per-framework infrastructure examples:

• SOC 2: change management in the delivery pipeline (approved pull requests before deploy).
• ISO 27001: risk-register-driven selection of controls such as encryption: the company lists its risks, then picks the controls that treat them.
• PCI DSS: segmentation (network separation that limits how many systems handle card data) of the card environment, plus quarterly external vulnerability scans (an approved vendor probes your internet-facing systems for known weaknesses).
• FedRAMP: a defined authorization boundary (the exact systems, networks and people included in the assessment) with continuous monitoring (ongoing reporting after approval, to the program office and the agencies using the service, such as regular vulnerability scan results).

Direct answer. Six months (about 26 weeks) is achievable for a 200-person SaaS company only if the scope is narrow (the production product and the people and systems that run it), an executive sponsor is named in week one, and the certification audits are booked early. The schedule is driven less by writing documents than by producing records that prove the system actually runs.

ISO/IEC 27001 is the international standard for an information security management system (ISMS): a managed, repeating process for deciding which risks matter and which controls address them. A certification body (an accredited auditing firm) certifies you in two audits: Stage 1 (a readiness review of your documented system) and Stage 2 (a test that the system is implemented and working).

Illustrative 26-week sequence

That puts four weeks between the two audits and two weeks of slack before month six. That slack is the number to defend. It exists because a minor nonconformity needs a corrective action plan, and a major one must be closed before a certificate issues, which may need a short follow-up audit; two weeks covers one such round, not two. The ISMS lead owns defending it, with the sponsor refusing requests that would use it up.

What an SoA row looks like (illustrative):

A control marked "No" needs a reason too, for example a physical-security control for a server room the company does not have because the data centers belong to the cloud provider.

What a record of operation looks like (illustrative): ticket SEC-142, "Q2 production access review", reviewer named, three stale accounts removed, closed on a dated day, export attached. One such record per quarter is what an auditor samples; the policy alone proves nothing.

What must exist before the auditor shows up (Stage 1). The scope, information security policy, risk assessment method and results, risk treatment plan, SoA, security objectives, and evidence staff are competent. The internal audit and management review must be complete before Stage 2, and some certification bodies want them before Stage 1, so ask yours; that is why they sit at weeks 14-20, not at the end.

Who is involved.

• Executive sponsor: owns the scope decision, risk acceptance (the formal decision by a named owner to live with a risk) and the management review.
• ISMS lead (security architect or analyst): runs the program and the register.
• Engineering and IT: implement access, logging, backup and change controls.
• HR: onboarding, offboarding, background checks, training.
• Legal/procurement: supplier contracts and legal requirements.
• Control owners in each team: the people accountable for running one control and who will be asked for its evidence.

Where it slips (most likely first).

1. Remediation engineering (for example single sign-on and MFA coverage, centralized logging) competes with the product roadmap. Fix: get the sponsor to rank it.
2. Scope creep: adding offices or a second product doubles the evidence. Fix: certify the core, extend at the next surveillance audit (the yearly follow-up audit that keeps the certificate valid).
3. Records of operation: a procedure written in week 8 has few months of evidence. Fix: start recurring controls (access reviews, supplier reviews) by week 10.
4. Auditor availability and findings: a major nonconformity (a significant or systemic failure to meet a requirement, as opposed to a minor, isolated lapse) must be closed before a certificate issues, so a bad Stage 2 can push you past month six.

What would change my call. No existing practices (no SSO, no ticketed change process) or a request to scope the whole company: I would say nine to twelve months and certify in phases.

Direct answer. A prescriptive framework (for example PCI DSS, which lists specific requirements and testing procedures) tells you what to do and the audit, run by an assessor (the qualified person who tests you against the standard), asks whether you did it. A finding is an auditor's written note that a requirement was not met. A risk-based or principles-based framework (for example ISO 27001, the international standard for an information security management system; SOC 2, an auditor's report on controls against published criteria; or the NIST Cybersecurity Framework, a US voluntary framework of outcomes grouped into functions) tells you the outcome and expects you to choose controls and justify them. Practically: with prescriptive, your work is closing gaps and documenting exceptions; with risk-based, your work is making and defending decisions.

Mixed estate of legacy and cloud

Worked example. A legacy database holds sensitive data and cannot encrypt at rest.

• Prescriptive: the requirement says data must be unreadable. You either migrate, or you build a compensating control (strong network isolation, access restricted to two service accounts, enhanced monitoring) and document why it meets the intent. If the assessor disagrees, it is a finding.
• Risk-based: you score the risk, document that encryption is not available, record the compensating measures and a migration date, and get the risk owner's signature (the person accountable for the system who accepts the remaining risk). The audit question is whether the reasoning is sound and applied consistently.

How I would implement across both. Use one baseline: the stricter of the two for each domain, applied everywhere it can be. Example: the prescriptive standard requires multi-factor authentication for access into the card environment, while the risk-based one only says to protect access in proportion to risk; the single baseline requires it for every administrator login on every system. Handle legacy exceptions in a single exception register (system, gap, compensating measure, owner, expiry date) so both audit styles read the same record. Illustrative row: "orders-db-legacy | no encryption at rest | access limited to two service accounts, query logging on | head of data platform | migration due 30 September". Keep the risk register as the source for decisions, so the risk-based audit sees reasoning and the prescriptive audit sees the compensating controls.

Pitfalls. Treating a prescriptive list as a risk argument ('we judged it unnecessary') fails. Treating a risk-based framework as a checklist leaves you unable to defend choices. Exceptions with no expiry date are a weakness in both, because a compensating control or accepted risk that is never reviewed quietly stops being true.

Direct answer. PCI scope means every system the PCI DSS (the card industry's security standard) requirements apply to, which is anything that stores, processes or transmits card data plus anything connected to those systems without separation. Segmentation means isolating the card systems so that out-of-scope systems cannot reach them, which is what lets the assessor (the qualified person who checks you against the standard) exclude everything else. Build a small, isolated card vault that is the only place the full card number (the primary account number, PAN) ever exists. Everything else in the platform handles only a token (a random stand-in value that cannot be turned back into the PAN without the vault). The cardholder data environment (CDE), meaning the systems that store, process or transmit card data plus anything connected to them, then shrinks to that vault and the capture path. You prove the boundary with a data-flow diagram, segmentation testing and evidence that nothing outside can reach the PAN.

Architecture

Browser --(card form served from capture domain)--> Capture service  [CDE]
                                                         |
                                           PAN encrypted, token returned
                                                         v
Main platform (orders, billing, support)  <-- token only -- Vault + key service  [CDE]
        |                                                        |
        +--- "charge token" request ---> Vault --> payment processor

• Capture: the card form is delivered by a minimal capture service in its own cloud account, so the main web application never receives the PAN. Keeping the capture page tiny matters because the assessor will also look at any scripts on that page.
• Vault: separate cloud account (or network) with default-deny rules, its own identity roles, no human access except an audited break-glass path (an emergency access route that is logged and reviewed afterwards), PAN encrypted with keys held in the cloud provider's key management service (KMS) backed by a hardware security module (a tamper-resistant device that stores keys and never releases them), using envelope encryption (the data is encrypted with a data key, and that key is itself encrypted by a master key in the KMS).
• Recurring billing: the billing job sends token plus amount to the vault, and the vault calls the processor. The billing system never detokenizes (turns a token back into the card number).
• Never stored: the card verification code after authorization.

Mapping requirement areas to cloud-native controls

The cloud provider's own compliance report covers only its part, so document the responsibility split.

What you must prove to the assessor.

1. A current data-flow diagram showing every path the PAN takes, and a list of every component in scope.
2. Segmentation holds: a penetration test that tries to reach the vault from out-of-scope networks, repeated on the schedule the standard requires.
3. Nothing outside can call 'detokenize': a token is out of scope only if it cannot be reversed without the vault.
4. No PAN leaks into logs, tickets, analytics, backups or support tools (shown by a data-discovery scan, a tool that searches storage for strings that look like card numbers).

Illustrative scope reduction: a platform of 40 services where the card number flows through all of them has 40 systems in scope. With the vault design, the capture service, the vault, the key service and three supporting systems (central logging, the admin access path and the segmentation firewall) are in scope: 6 of 40, and the other 34 handle tokens only.

If health data is also held (HIPAA). HIPAA is the US health-privacy law, a separate regime from PCI that applies only if the platform holds health data. In that case, keep it in a separate enclave (an isolated environment) with separate keys and access roles. HIPAA's encryption specification is labelled 'addressable', which means implement it or document an equivalent measure, not that it is optional, and in practice you would encrypt here anyway.

Trade-offs. A vault is a single high-value target and an on-call burden. The alternative, using the processor's token vault, shrinks scope further and is preferable whenever the business reason for keeping cards allows it. Ask the question once more before building.