Effivity for PCI DSS: running the twelve requirements as a year-round programme

Why PCI DSS needs a system between assessments

An organisation can pass one assessment on effort alone and fail the next because nothing kept running. The requirements are written that way on purpose. External and internal scans are quarterly, access to the CDE is reviewed every six months, logs are reviewed daily, people are trained each year, and the incident plan, the scope and the policy set are all revisited annually. A QSA does not ask whether these activities exist; it asks for the occurrences across the year and checks the dates.

Effivity, Sterling's ISO and GRC automation software, holds that calendar. Each periodic activity becomes a task with an owner, a due date, reminders and escalation, and closing the task attaches the output that proves it happened. The result is a programme you can show, not a folder assembled before fieldwork. Which validation route you are on, ROC or SAQ, is covered in the validation guide; the register described here serves both.

The requirement register: twelve requirements, one owner each

The register is built from the gap analysis findings, not from a generic library. For each requirement it records how your organisation meets it, the systems in scope, the accountable owner and a deputy, the documents that govern it and the records an assessor will expect. Requirements that do not apply to you are marked with the reason, because an SAQ or ROC still has to explain them.

The task calendar for recurring PCI DSS activities

Recurring work is what slips between assessments, and it is where the calendar earns its place. Each task is written so the person doing it knows what to attach.

• Quarterly scans. One task per quarter for the external ASV scan and one for the internal scan. The owner attaches the report; a failing scan opens a Non-Conformance record, and the rescan that passes closes it.
• Access reviews. Every six months each system owner attaches the account list with a keep or remove decision, and the approver signs it off.
• Log review. Daily review happens in your monitoring tools; Effivity holds the periodic confirmation that it took place and the handling of any alert or control failure.
• Penetration and segmentation tests. Scheduled at the frequency the standard sets for your entity type, and again after significant change, with findings tracked to retest.
• Training. Security awareness at hire and each year, plus role training for developers and payment staff, recorded against each person in HR.
• Annual tasks. Scope confirmation, policy review, incident plan exercise and the review of each provider, each with its own due date and sign-off.

Where a frequency is left to your own targeted risk analysis, such as how often point-of-interaction devices are inspected, the task links to the analysis that justifies it.

Third-party providers and the dates on their AOCs

Payment gateways, hosting companies, call recording vendors and managed security providers can all affect the security of card data, and PCI DSS makes you responsible for knowing which. Effivity's vendor risk register lists each provider with the service it delivers, whether it stores, processes or transmits account data on your behalf, the responsibility matrix agreed with it and the date of its latest Attestation of Compliance.

The date matters. A provider validates annually, and an AOC more than a year old tells you nothing about the current state. A task ahead of each anniversary prompts the owner to request the new document, check that the services you use are inside its scope and record what was received. Providers without an AOC are shown as such, with the evidence you will rely on instead.

Incidents, missed tasks and targeted risk analyses

Security events are logged in Information Security Incident Management from detection to review, including whether card data was involved and who was notified under your response plan. The annual exercise of that plan is recorded in the same place, so the assessor sees both the plan and proof it has been tested.

When a periodic task is missed, the accurate record is the useful one: log it late, open a Non-Conformance record with the cause and the correction, and run the activity. A task closed later with an earlier date is the kind of record that damages trust in everything else.

The targeted risk analyses required by the current version sit in Information Security Risk Management, each tied to the requirement it supports and reviewed at least once a year. Changes to the environment, a new payment channel or a new provider, are assessed there for their effect on scope.

What is configured at the start of the engagement

Configuration follows the gap analysis, so the software reflects your environment from the first week. Sterling's consultants typically set up:

• the requirement register, with applicability decisions and owners agreed in workshops;
• the document set: information security policy, procedures and configuration standards, with approval and yearly review dates;
• the asset inventory for the CDE and connected systems, including payment terminals;
• the recurring task calendar, with first due dates planned back from the target assessment date;
• the provider register with current AOCs;
• user access for owners, approvers and management, and dashboards showing what is due, late or open.

Users and the access period are confirmed in the proposal.

What the QSA sees, and what Effivity does not do

For each requirement the assessor asks for documents, observes configurations and samples records. With the register in place, every request points to one entry: the policy with its review date, the list of completed quarterly scans, the access reviews for the period, the provider AOCs. How the assessor receives the material, by export or supervised access, is agreed with the QSA company before fieldwork. An internal security assessor, where you have one, works from the same register; the internal audit guide covers that role.

Limits worth stating plainly:

• Effivity does not issue a ROC, an SAQ or an AOC, and there is no PCI DSS certificate for it to produce.
• It does not segment networks, encrypt data or run scans; those controls live in your technology.
• It does not decide scope or accept risk; people do, and the record shows who and when.
• A task closed without doing the work is still a failed control; assessors test the substance behind the record.

Effivity for PCI DSS: questions buyers ask