Om du lagrar PAN (kortnummer) måste det absolut krypteras.
Om du lagrar kortinnehavarens namn, utgångsdatum, utfärdandenummer (och de kan kopplas till PAN) så bör de vara krypterad, men (min förståelse) är att det inte är absolut nödvändigt. PCI-DSS anger bara att PAN:et minst måste vara krypterad.
CV2/AVS/CSC-koden kan inte lagras efter auktorisering, och helst skulle du vilja bevisa att den inte är lagrad alls (t.ex. - sparas bara i minnet medan auktorisering utförs)
Angående certifikat/nycklar - du kan bara använda en nyckel för kryptering av alla kortrelaterade data. Bästa praxis är att inte använda nycklar för flera ändamål, så om du har annan (icke kortrelaterad) data som är krypterad, använd då en separat nyckel för det.
Den svåraste delen är en som du inte riktigt har nämnt i detalj - och det är nyckelhantering. För att uppfylla PCI-kraven måste nyckeln lagras i en separat fysisk låda till databasen, och du behöver kunna byta nyckel minst en gång per år. SQL 2008 stöder detta med Extensible Key Management (EKM)
Alla dessa punkter diskuteras bäst med en oberoende QSA (Qualified Security Assessor) som du någon gång kommer att behöva involvera oavsett för att uppfylla PCI-efterlevnad. Din QSA kommer att kunna vägleda dig i frågor som denna, och i slutändan är det hans/hennes råd som du bör följa för att uppfylla efterlevnad.
Det är värt att nämna att de flesta människor snart inser hur mycket av en börda PCI-efterlevnad kan vara, och försöker minimera den bördan genom att använda en betalningsgateway från tredje part. De flesta betalningsgateways låter dig utföra auktorisering/avräkning och lagra kortuppgifterna på deras (redan PCI-kompatibla) servrar. Du behöver då bara lagra ett TokenId som refererar till dessa betalningsuppgifter om du skulle behöva utföra ytterligare debiteringar/återbetalningar på det kortet.
Lycka till i alla fall!