Hvis du gemmer PAN (kortnummeret), skal det absolut være krypteret.
Hvis du gemmer kortholders navn, udløbsdato, udstedelsesnummer (og de kan knyttes til PAN), så bør de være krypteret, men (min forståelse) er, at det ikke er absolut nødvendigt. PCI-DSS angiver kun, at PAN'et som minimum skal være krypteret.
CV2/AVS/CSC-koden kan ikke gemmes efter godkendelse, og ideelt set vil du gerne bevise, at den slet ikke er gemt (f.eks. - kun gemt i hukommelsen, mens du udfører godkendelse)
Med hensyn til certifikater/nøgler - du kunne bare bruge én nøgle til kryptering af alle kortrelaterede data. Bedste praksis er ikke at bruge nøgler til flere formål, så hvis du har andre (ikke-kortrelaterede) data, der er krypteret, så brug en separat nøgle til det.
Den sværeste del er en, du ikke rigtig har nævnt i detaljer - og det er nøglestyring. For at opfylde PCI-kravene skal nøglen opbevares på en separat fysisk boks til databasen, og du skal have mulighed for at ændre nøglen mindst årligt. SQL 2008 understøtter dette med Extensible Key Management (EKM)
Alle disse punkter diskuteres bedst med en uafhængig QSA (Qualified Security Assessor), som du på et tidspunkt bliver nødt til at involvere uanset for at opfylde PCI-overholdelse. Din QSA vil være i stand til at vejlede dig i spørgsmål som dette, og i sidste ende er det hans/hendes råd, som du bør følge for at overholde overholdelse.
Det er værd at nævne, at de fleste mennesker snart indser, hvor stor en byrde PCI-overholdelse kan være, og ser efter at minimere denne byrde ved at bruge en 3. parts betalingsgateway. De fleste betalingsgateways giver dig mulighed for at udføre godkendelse/afregning og gemme kortoplysningerne på deres (allerede PCI-kompatible) servere. Du behøver derefter kun gemme et TokenId, der refererer til disse betalingsoplysninger, hvis du skulle have brug for at foretage yderligere debiteringer/refusioner på det pågældende kort.
Held og lykke i hvert fald!