Compliance Frameworks and Certification Standards Questions
The major security compliance frameworks and certification standards and how to achieve and maintain them: SOC 2 (Type I and II, Trust Services Criteria), ISO/IEC 27001 and 27701, NIST CSF and SP 800-53, CIS Controls, PCI DSS (scoping, the cardholder data environment, segmentation and card-on-file architecture, staying compliant as software ships), and FedRAMP (baselines, authorization boundary and authorization paths). Covers what each framework governs, mandatory regulation versus voluntary standard (including regulated product standards versus a voluntary certification), prescriptive versus principles-based approaches, how control families map to organizational practices, choosing and sequencing frameworks and making the cost case, which framework mandates versus merely expects a practice such as penetration testing, reading vendor attestations, scoping and gap analysis including which gaps block certification, certification roadmaps, sustaining compliance after the first report, and harmonizing overlapping requirements across standards and laws into one traceable control set. Excludes designing and testing individual controls, building audit evidence packages, compliance tooling, and the detailed text of privacy laws, which are covered elsewhere.
An e-commerce company takes card payments and has never scoped PCI DSS. How do you work out what is in scope, how do you find where card data actually lives and flows, and what can you do to shrink the scope? Include how using a hosted payment page changes the merchant's obligations.
Sample Answer
Direct answer
PCI DSS (Payment Card Industry Data Security Standard) applies to entities that store, process or transmit cardholder data, or that can affect the security of the CDE (cardholder data environment: the systems and people touching card data plus anything connected to them). Scope it by tracing the card from entry to bank, shrink it by not touching card data at all, and note that a hosted payment page moves most of the burden to the provider without removing yours. It is enforced contractually by card brands and acquirers (the merchant's payment bank), not by statute.
1. Work out what is in scope
List every system that stores, processes or transmits card data, then everything connected to them without segmentation (network separation proven by testing), plus security systems that protect them (authentication, logging).
2. Find where card data actually lives
- Draw data-flow diagrams from browser to acquirer, including refunds, support tools and exports.
- Interview teams: finance and support often hold card numbers in tickets, spreadsheets or call recordings.
- Scan databases, logs, backups and storage buckets for card number patterns.
A worked trace (illustrative merchant): the checkout form posts to the merchant's web server, which forwards to the payment gateway. Following one purchase turns up five places the number lands: the web server (processes it), the order database (a developer's notes field holds a full number), the request log (the number was captured in a logged request body), a support ticket (a customer pasted it), and the gateway and acquirer. In scope: the web server, order database, log store and support desk, the network segment they share, and the authentication and logging systems that protect them. Cleaning the notes field and logs, redacting tickets, and moving card entry to a hosted page leaves the provider's page and the link to it as the merchant's remaining scope.
3. Shrink scope
- Stop storing what you do not need; sensitive authentication data (the card security code, full magnetic-stripe data and PINs) must not be kept after authorization (Requirement 3.3.1).
- Replace card numbers with tokens (random stand-in values) from a payment provider.
- Use a hosted payment page or hosted fields so card data never reaches your servers.
- Segment what remains and consolidate it.
4. Hosted payment page: what changes
With a redirect to the provider's page, the merchant servers never see card numbers. You still own: choosing the provider and keeping its current attestation of compliance (the signed statement that it passed its own PCI assessment), knowing which requirements it covers versus you, protecting the page that sends customers to it (a tampered link or script sends them to a fake page), access to the provider's portal, incident response, and the annual self-assessment. The shortest merchant questionnaire is SAQ A (Self-Assessment Questionnaire A, for merchants that fully outsource card entry and handling). Its criteria include that every element of the payment page comes only and directly from a PCI-compliant provider and that the merchant's site is not susceptible to attacks from scripts, so confirm the current criteria with your acquirer or assessor.
Core requirement categories and recurring tasks
Secure network configuration, protecting stored account data, vulnerability management, strong access control, logging and testing, and policy. Two recurring tasks: external vulnerability scans every quarter by an Approved Scanning Vendor (a company the PCI council approves to probe your internet-facing systems for known weaknesses, Requirement 11.3.2), and cryptographic key management for any keys protecting card data. Whatever scoping leaves in the CDE is what these requirements apply to, and the scoped system list also decides which questionnaire or assessment the merchant completes and files with its acquirer as an attestation of compliance.
A cross-border data processing service must satisfy both GDPR and SOC 2. How would you translate the requirements of each into concrete architecture decisions, record them so they stay traceable for later audits, and handle the places where the two do not line up?
Sample Answer
Direct answer
Treat the two as different kinds of thing. GDPR (the EU General Data Protection Regulation) is a law with fixed obligations, so I would turn each obligation into a design decision. SOC 2 is a voluntary attestation: an independent auditor reports on whether the controls the company chose meet the AICPA Trust Services Criteria (the published control criteria in five categories: Security, Availability, Processing Integrity, Confidentiality, Privacy). Only Security is mandatory in a SOC 2; the other four are chosen by scope. I would build one control set, record every decision in a decision log that points to the requirement and to its evidence, and list the conflicts openly with a named owner.
Step 1: Fix the role, then annotate the data flows
A "cross-border data processing service" usually acts as a processor (it handles personal data on a customer's behalf; the customer is the controller and decides why the data is used). Counsel or the contract confirms that role. First I would draw a data-flow diagram and tag each flow with: data categories, region of origin, storage region, which sub-processors (vendors the service uses) touch it, and whether it leaves the EU/EEA (the EU plus Iceland, Liechtenstein and Norway).
Step 2: Requirement to architecture decision
Art. 28 lists what a processor must do under its contract with the controller, Art. 30 requires the processor's records, and Arts. 44-46 govern moving data out of the EU/EEA.
| Requirement | Design decision |
|---|---|
| GDPR Art. 28(3)(a): process only on documented instructions | Purpose tags on datasets; no use outside the customer's contracted purpose |
| Art. 28(3)(d) with Art. 28(2): no sub-processor without the controller's prior written authorisation, either specific to that vendor or general (a standing authorisation, in which case the processor must announce each intended change and give the controller the chance to object) | Sub-processor registry that records which kind of authorisation each customer gave; the deploy pipeline blocks new vendor integrations until the authorisation or notice-and-objection step is complete |
| Art. 28(3)(e): help with data subject requests (requests from the individuals the data is about, such as access or erasure) | Searchable customer-keyed data model; erasure API that also reaches search indexes and caches |
| Art. 28(3)(g): delete or return all personal data at contract end, as the controller chooses, and delete existing copies unless EU or Member State law requires storage | Per-customer encryption keys; deletion plus key destruction (data encrypted under a destroyed key can no longer be read, which is also how copies in backups become unusable before the backup rotates out; counsel confirms the customer accepts this) |
| Art. 30(2): processor records, incl. transfers and security measures | Generate records from the data-flow tags |
| Arts. 44-46: transfers outside the EU/EEA need an adequacy decision (the European Commission has ruled the destination country protects data equivalently, Art. 45) or safeguards such as standard contractual clauses (Commission-approved contract terms, Art. 46) | EU-resident storage by default; any non-EU access goes through documented safeguards and a legal-reviewed transfer risk assessment (a written check of whether the destination country's authorities could reach the data in ways the clauses cannot prevent) |
| SOC 2 Security (access, change management, monitoring) | SSO plus MFA, least-privilege roles, reviewed pull requests, centralized logging |
| SOC 2 Confidentiality / Availability (if scoped) | Encryption at rest and in transit; multi-zone deployment, tested backups |
Step 3: Traceability from decision to evidence
Each decision gets one log entry: ID, requirement references (GDPR article, SOC 2 criterion), the control, the owner, the evidence source and where it lives. Example: D-07 "Non-EU support access is disabled by default": references Art. 44-46 and SOC 2 criteria CC6.1 to CC6.3 (the logical-access criteria: who may log in to and use systems); the control is a break-glass role (emergency access that is normally off, granted for a short time and logged) that expires after a set period; evidence is the access-grant log plus quarterly access-review tickets. An auditor can then walk from the requirement to the decision to the evidence, and from a log record back to the requirement. For a SOC 2 Type II (which tests operation over a period, unlike Type I, which looks at design at one date), the evidence must be generated continuously, so I prefer evidence produced by the pipeline over screenshots.
Step 4: Where they do not line up
- Deletion versus retention. GDPR requires deletion or return at contract end. SOC 2 auditors want logs and evidence. Resolution, owned by the security lead with legal sign-off: keep security and audit logs free of customer content, with identifiers pseudonymized (replaced by tokens that point back to a person only through a separately held key), and keep them for a set retention period. An illustrative log line is
2026-03-02T09:14:07Z actor=u_8f3a91 tenant=t_204 action=export result=ok, with no names, emails or payloads, kept for 12 months (illustrative; the contract and counsel set the real figure). Pseudonymized data is still personal data under GDPR (the tokens can be linked back to a person with the separately held key), so this is a managed exception and not a clean escape: the contract should say that security and audit logs are kept for the stated period after termination, I would restrict the actor field to the service's own staff and systems where the audit needs allow it, and the customer must accept this. SOC 2 itself is not a law that overrides the deletion duty, and it sets no fixed log retention figure; the period comes from the auditor's testing window and the contract. After the retention period the lines are deleted on a schedule, so the retained evidence is limited in content and time, and the deletion duty is met for everything else. Backups are deleted on the normal rotation cycle, and the customer is told how long that takes. - Breach clocks. Art. 33 lets the controller take up to 72 hours from becoming aware of a breach, and requires the processor to notify the controller without undue delay. Neither sets the processor's hours, so the contract sets them (I would propose a short fixed window, for example 24 hours; this is illustrative and the customer may demand shorter), and the SOC 2 incident-response control is aligned to that window.
- Scope. SOC 2 covers only what management puts in scope and does not by itself show GDPR compliance, so I would never sell it as proof. If Privacy is optionally in scope, it still measures against the company's own notice and commitments, not the GDPR text.
- Transfer legality. No SOC 2 report answers whether a transfer is lawful. Counsel decides that and the DPO (data protection officer, the person appointed to advise on and monitor GDPR compliance) or customer signs off; engineering enforces it with regional isolation.
Trade-off and what would change my call
Region-pinned storage costs more (duplicate stacks, harder support) but removes most transfer analysis. If customers are all in one jurisdiction, I would not build multi-region at all.
Your CIO asks why the company is funding a SOC 2 report, an ISO 27001 certification, a PCI DSS program and a FedRAMP effort at once, when 'compliance' sounds like one thing. Explain to the CIO which of these the company is actually obliged to do, who imposes the obligation, and what happens if it falls short, and why a company would take on one that nobody requires.
Sample Answer
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).
| Framework | Legal, contractual or voluntary | Who imposes it | If you fall short |
|---|---|---|---|
| PCI DSS (card payment security) | Contractual | Card brands and acquirers (the bank processing your card payments), via the merchant agreement | Demands to fix findings by a deadline, fines the card brands charge that the acquirer passes on, and in the worst case the acquirer ends the agreement so the company can no longer take cards |
| FedRAMP (Federal Risk and Authorization Management Program: the US government's process for approving cloud services that hold federal data) | Required by US federal policy for cloud services holding federal data | Federal agencies, through the FedRAMP program office | Cannot sell that service to agencies until it holds a FedRAMP authorization from an agency sponsor (the agency formally approves it for use) or, on the sponsorless Program Certification path, a certification from the program office. Under the 2026 path rules, sponsorless certification covers the 20x process at Classes A to C and the Rev5 process at Class A only; Class D always needs an agency sponsor (Class A is a new pilot baseline, B is the former Low plus Li-SaaS, C is Moderate, D is High). Providers that lost a sponsor have only a limited, time-boxed Rev5 pipeline at Classes B and C |
| SOC 2 (CPA firm report) | Voluntary | Customers' procurement teams | Lost or delayed deals: a prospect's security review asks for the report before signing, and the deal waits while the audit is arranged and run |
| ISO 27001 (certification of a management system) | Voluntary unless law or contract demands | Customers, sometimes tenders | Lost or delayed deals |
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).
A SaaS startup's first federal agency prospect says it must be 'FedRAMP authorized.' Explain what that means, how the authorization paths work and who has to sign off, how heavy the effort is compared with the SOC 2 the startup already has, and what you would ask before committing.
Sample Answer
Direct answer. FedRAMP (the Federal Risk and Authorization Management Program) is the US government's standard security assessment for cloud services that federal agencies use. 'FedRAMP authorized' means a cloud offering was assessed against a defined set of NIST SP 800-53 security controls (the NIST catalog of security and privacy controls) and a US government authorizer accepted the residual risk (the risk that remains after the controls are applied). It is a much heavier effort than SOC 2, and the first thing I would do is find out what impact level the agency will put in the service, because that decides whether a sponsoring agency is required or FedRAMP itself can certify you.
Program structure has been changing. FedRAMP's Consolidated Rules for 2026 (mandatory from January 1, 2027) describe two routes: Program Certification, issued directly by FedRAMP with no agency sponsor, and Agency Certification, where a federal agency first authorizes the service and then sponsors it. They also describe two assessment styles: FedRAMP 20x, built around automation and machine-readable evidence, which can go through Program Certification, and Rev5, the older document-based style built on NIST SP 800-53 Revision 5, which mostly goes through an agency. FedRAMP now labels certification classes A to D: A is a new pilot baseline, B is roughly the old Low plus Li-SaaS, C is Moderate and D is High, and a class describes the depth of assurance a provider supplies, not the agency's data impact. Program Certification covers 20x at Classes A to C and Rev5 at Class A only. Rev5 at Classes B and C has only a limited, time-boxed pipeline for providers that lost a sponsor, and Class D always needs an agency sponsor. FedRAMP stops accepting Rev5 applications on June 11, 2027, and the older joint board route was replaced. Material from customers still says "FedRAMP authorized", so treat "authorized" and "certified" as the same goal, and read the current FedRAMP site before quoting dates, because they have been moving.
How authorization works, generically
- Agency route: a sponsoring agency's authorizing official (AO) (the senior official who formally accepts the risk of running the system) reviews the security package and issues the authorization. Other agencies can then reuse it.
- Program-level route: the FedRAMP program office reviews the package itself, without a single sponsoring agency.
- In both, an accredited third-party assessment organization (3PAO) independently tests the controls, and after authorization the provider must keep proving controls work (continuous monitoring: recurring scans, a plan to track fixes, and periodic reporting).
- Sign-offs: you (system owner), the 3PAO's assessment, the AO or program office decision. The impact level (historically Low, Moderate or High, based on the damage if the data were lost or exposed) sets how many controls apply: the Rev5 Moderate baseline has 323 controls, counting enhancements, where SOC 2 has no fixed list and you choose yours.
Compared with SOC 2 and ISO 27001
| SOC 2 | ISO 27001 | FedRAMP | |
|---|---|---|---|
| What it is | An auditor's attestation report (a CPA firm's signed opinion) on controls | A certificate for a management system | A government authorization to operate |
| Control list | Principles-based (Trust Services Criteria, the AICPA's published control requirements), you choose controls | Risk-driven, you justify choices | Prescriptive NIST SP 800-53 baseline |
| Evidence | Samples over an observation window | Audit samples, internal audit | Detailed system security plan (the document describing the system and how each control is met) and tested controls |
| Monitoring | Annual re-audit | Annual surveillance audits | Ongoing reporting to the government |
| Who accepts | Your customer decides | Your customer decides | A US government official |
SOC 2 helps (policies, access control, change management evidence get reused), but it is not a substitute: the control list is far larger and more prescriptive, the system boundary (the exact set of components, data flows and people the authorization covers) must be documented in detail, and cryptography and incident reporting requirements are specific.
What I would ask before committing
- Is the agency willing to sponsor, and does the deal value justify the effort? A sponsor is always required for Class D, and for Rev5 at Classes B and C apart from the limited pipeline for providers that lost one. It is not required for Program Certification, which covers 20x at Classes A to C and Rev5 at Class A only, so a refusal narrows the options rather than ending them.
- What data and impact level will the agency put in the service?
- Which route will the agency accept today?
- Is our cloud provider already authorized, so we inherit controls (rely on the provider's already-assessed controls instead of building our own) rather than building them?
- Can we carve out a government-only environment so the commercial product is untouched?
- Staffing: who owns documentation, who owns continuous monitoring?
Commitment. Do not promise a date to the prospect. Run a gap assessment against the control baseline first, and decide with the sales team.
A client's e-commerce platform has the card form, checkout API and order database in one network, and their assessor says everything is in PCI scope. Compare the architectural options for shrinking that scope, recommend one, and cover the cost, customer experience and the obligations you could not avoid.
Sample Answer
Direct answer
Recommendation: move card capture to the payment provider using hosted fields or an iframe, store only the provider's token in the order database, and keep the checkout API token-only. That removes card data from the client's network at modest customer-experience cost. Choose a full redirect instead if the client cannot protect its own checkout page scripts.
Options compared (four)
| Option | Scope effect | Cost | Customer experience | Main trade-off |
|---|---|---|---|---|
| 1. Full redirect to provider page | Largest reduction | Lowest build effort | Customer leaves your site, weaker branding | Least control of conversion |
| 2. Iframe or hosted fields | Large reduction | Moderate build effort | Looks native | Your page surrounds the form, so script integrity (knowing which scripts load on your checkout page and detecting changes to them) matters |
| 3. JavaScript or direct post to provider | Smaller reduction | Moderate | Fully native | Your page handles card entry, so more requirements stay |
| 4. Segment and keep in-house card handling | Network still in scope | Highest (assessment, controls, operations) | Fully native | Full burden stays |
What the options mean
In a full redirect the customer types the card on the provider's own web address. An iframe is the provider's form embedded in your page inside a frame, and hosted fields are the same idea with individual provider-controlled input boxes: the card is typed into the provider's code, which your page's scripts cannot read. In direct post or JavaScript integration the card is typed into your own page and goes straight to the provider, so your page's code can see the number as it is typed. That is why option 2 leaves less in scope than option 3: with option 3 a malicious script on your page can copy card numbers, so more requirements stay yours, and merchants in that position usually complete a longer questionnaire than SAQ A.
Why option 2
It keeps checkout branding, avoids running a CDE (cardholder data environment: systems that handle card data), and typically qualifies for a lighter self-assessment (a questionnaire the merchant fills in itself, instead of an on-site assessment by a Qualified Security Assessor, an assessor company PCI certifies) than options 3 and 4. Cost depends on drivers rather than a fixed figure, so get quotes: for option 2, provider transaction fees, integration engineering, and migrating historical stored card data to tokens or deleting it; for option 4, add the assessor's fees, segmentation testing, quarterly scans, and staff time to run the controls every year.
Obligations you cannot avoid
- Provider management and keeping its attestation of compliance (the signed statement that it passed its own PCI assessment) on file.
- Protecting and monitoring scripts on your checkout page, since attackers target pages that merely frame the form: a skimming script slipped into one third-party tag on the checkout page can overlay a fake card form on top of the real frame.
- Access control to the provider portal, policies, incident response, and the annual attestation.
- The assessor (the Qualified Security Assessor) and the acquirer (the merchant's payment bank) decide final scope and validation level.
What changes the call
Weak front-end engineering or release control: choose option 1. A need for card data in your own systems (for example, custom fraud models): keep a small segmented CDE and accept the cost.
Unlock Full Question Bank
Get access to all 10 Compliance Frameworks and Certification Standards interview questions and detailed answers.
Sign in to ContinueJoin thousands of developers preparing for their dream job.