In these modern times, "PCI" is no longer the slot into which you insert your computer's network adaptor. No: PCI stands for the Payment Card Industry, and although it's regarded right now as a set of best-practice guidelines for protecting against credit/debit card fraud, you can be sure that before long the banks will stop recommending compliance and begin insisting on it.

If you accept payments using debit or credit cards, then, you'd better take notice of PCI.

Of course, there's a vast amount of common sense regarding how you accept, process and store payment card information. So unsurprisingly, a large portion of PCI is an enumeration of common-sense ideas. Let's walk through the key points, of which there are a dozen.

1: Install and maintain a firewall configuration to protect cardholder data
Of course, you'd never consider running an ecommerce site - or any type of externally-connected network, for that matter. But take note of the third word: maintain. Most of us have installed firewalls, but do we check on them every so often to ensure that, for instance, we've no old rules that shouldn't be there any more, or there are user IDs belonging to users who've left the company. Most firewalls are installed and initially configured pretty well, but far too many lack maintenance.

2: Do not use vendor-supplied defaults for system passwords and other security parameters
No s**t, Sherlock, but it's easily done. Many sure you change EVERY default password - remember an intruder only needs read-only access to steal information.

3: Protect stored cardholder data
Another obvious one, but do you do this adequately? What do you do, for instance, with the three-digit security codes from the backs of people's cards? (Hint: if the answer isn't "dispose of them securely as soon as they've been used for authorisation" you're doing it wrong). How many members of staff have access to full card numbers? (Another hint: if the answer isn't "a select few, and only after intense authentication" you're doing that wrong too). If you absolutely need to store data, do it safely. If you don't need to store it, chuck it away securely, or at the very least blank out all but the last four digits of a card number in order to render it unusable.

4: Encrypt transmission of cardholder data across open, public networks
The obvious, easy bit of this one is to get yourself an SSL certificate on your Web site. But make the effort to consider ways in which card data might get shipped outside your network - for example, if you're having problems with your Merchant Services software and the supplier asks you to send a sample data file for them to use in debugging.

5: Use and regularly update anti-virus software
The easiest of the bunch, this one. Ideally use two or three different AV packages in parallel, to maximise your chances of catching new viruses as they appear.

6: Develop and maintain secure systems and applications
Following the easiest of the lot comes the hardest of the lot. It's a simple sentence, but it's a vast, open-ended problem. You don't have control over the security of most of your applications, because you didn't write them. What you can do, of course, is disable components that communicate willy-nilly across the Internet, auto-update themselves without warning, and so on. And of course, you can set your firewall to prohibit connections by default in order to give a further level of protection.

7: Restrict access to cardholder data by business need-to-know
This is really an extension of item 3. Only people who need to see cardholder information should be allowed so to do, and then only via strong authentication mechanisms.

8: Assign a unique ID to each person with computer access
Audit trails are the security manager's best friend. You need to be confident that if your systems say that something was done using John Smith's user ID, it was John Smith that did it. If you can't be confident of that, you're screwed and you should start brushing up on how to make a futile attempt at defending yourself against John Smith at his tribunal for unfair dismissal. Oh, and what "duty of care" means, ready for when the lawsuits start to fly.

9: Restrict physical access to cardholder data
Remember that a disk is theoretically accessible not just via the network, but by strolling up to the server and pulling it out. And make sure you absolutely minimise the amount of cardholder data that finds its way onto reports, both paper and on-screen (if someone has something on the screen, it's generally very easy to send it to a printer).

10: Track and monitor all access to network resources and cardholder data
We're back on audit trails again, but this is a good point: don't just track and audit everything - look at the information on a regular basis. There's no point logging nefarious activity if you don't actually detect it because you never physically examine the information. It's essential, then, that your logging is comprehensive but concise, and that you have tools that allow you quickly to get to the key data. If the useful detail is buried among gigabytes of pointless rubbish, your audit trail is worthless.

11: Regularly test security systems and processes
We all test our security systems and processes regularly, of course. You don't? Well, you should. It doesn't have to be a complex, expensive task. While it's good to do proper penetration testing from time to time on key systems (which can, of course, cost a fortune) think more along the lines of ensuring that you have controls over user access, who can amend firewall rules, whether users are removed from systems when they leave, who grants user access and to what, and so on. So pick a user who you know left recently and go digging to see if there are traces of that user left. Get your department secretary to request access to a system that requires someone's sign-off, and see whether the IS department follow the process. It's often the simple stuff that catches you out.

12: Maintain a policy that addresses information security
Security systems are useful, but they're only good when they're configured correctly and used properly. You need policies and procedures for disciplinary reasons, of course, but that's actually a fraction of their usefulness. 10% of your policies should deal with what happens for non-conformers, but the remaining 90% is there to explain to the users what they're meant to do. You can't have rules that say: "You must not do X" if you don't also have a process that explains how people are meant to behave, because you can't assume users will gain this knowledge by osmosis.

You'll agree, then, that PCI is largely an exercise in common sense. Unfortunately, many of the card services providers have yet to get their acts together (more than once recently I've had clients tell me that their card services company is insisting that they adopt PCI, but has no mechanism for assisting with, or even verifying, compliance) which means you're on your own for the moment. The good news, of course, is that there's nothing very hard. But what you do need is your senior management to fight you corner, because while you can address a portion of PCI using technology, the majority of it is procedural. And the only way to make procedures work is for the entire organisation to adopt, conform and enforce them.