<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: PCI 101</title>
	<atom:link href="http://startupsecurity.info/blog/2008/11/03/pci-101/feed/" rel="self" type="application/rss+xml" />
	<link>http://startupsecurity.info/blog/2008/11/03/pci-101/</link>
	<description>Security, for Startups</description>
	<lastBuildDate>Mon, 21 Sep 2009 16:57:21 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Damon Cortesi</title>
		<link>http://startupsecurity.info/blog/2008/11/03/pci-101/comment-page-1/#comment-13</link>
		<dc:creator>Damon Cortesi</dc:creator>
		<pubDate>Tue, 04 Nov 2008 03:33:21 +0000</pubDate>
		<guid isPermaLink="false">http://startupsecurity.info/?p=76#comment-13</guid>
		<description>Fantastic points, Mike. I&#039;ll re-iterate the specific you mentioned about avoiding PCI compliance: &quot;It’s simple, just don’t ever store, process, or transmit cardholder data - let someone else do it for you.&quot;

As an example, right after I posted this somebody asked me about a particular shopping cart app and if it was a secure solution. My answer, similar to yours, as long as they redirect to a payment site it should be fine.

Handling credit card data in a secure fashion is no easy task, which is why it&#039;s much better to let others with the resources to do so, tackle that problem.</description>
		<content:encoded><![CDATA[<p>Fantastic points, Mike. I&#8217;ll re-iterate the specific you mentioned about avoiding PCI compliance: &#8220;It’s simple, just don’t ever store, process, or transmit cardholder data &#8211; let someone else do it for you.&#8221;</p>
<p>As an example, right after I posted this somebody asked me about a particular shopping cart app and if it was a secure solution. My answer, similar to yours, as long as they redirect to a payment site it should be fine.</p>
<p>Handling credit card data in a secure fashion is no easy task, which is why it&#8217;s much better to let others with the resources to do so, tackle that problem.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mike</title>
		<link>http://startupsecurity.info/blog/2008/11/03/pci-101/comment-page-1/#comment-12</link>
		<dc:creator>Mike</dc:creator>
		<pubDate>Tue, 04 Nov 2008 03:04:41 +0000</pubDate>
		<guid isPermaLink="false">http://startupsecurity.info/?p=76#comment-12</guid>
		<description>Damon, you make an excellent point and one that companies need to really be aware of.  One of the problems with any new topic, such as PCI, is that the volume of information can be overwhelming.  

When small startups try to direct the details and differences between: PCI DSS, PCI PIN, and PCI PA-DSS it can be overwhelming.  Throw in acronyms such as DSE, ISO, TPP, and people just stop listening.

That is why it&#039;s very important that we digest the information for our target audience.  I&#039;ve taught the information to large and small companies alike in various industries, and each constituent has a different take home message pertinent to they way they do business.

If there is one take home message I would have for your audience it&#039;s that PCI only applies to you if you &quot;store, process, or transmit cardholder data.&quot;  Now I don&#039;t have to even define cardholder data before you ask how to get this compliance monkey off your back.

It&#039;s simple, just don&#039;t ever store, process, or transmit cardholder data - let someone else do it for you.  In reviewing a shopping cart recently they had two modes of operation:

1) Solutions that don&#039;t require customers to redirect
2) Systems that redirect your customers to a payment site and then back

Small startups want to choose number two because it causes the end user to enter their credit card data at the third-party vendor, instead of accepting it themselves.  Even if they only accept it for a second on their one web server, now that server is in scope for PCI compliance.

So, want to do away with PCI?  Don&#039;t accept cardholder data online, and let someone else do it for you.

But what if a governing body asks me to validate compliance, or provide them a report stating we are doing everything right?  Well, you can confidently fill out the Self-Assessment Questionnaire (SAQ) A.  This means you only do card-not-present transactions and all Cardholder Data functions are outsourced.  This is only 11 questions, instead of the 224 question long SAQ D (they are labeled A, B, C, and D.)</description>
		<content:encoded><![CDATA[<p>Damon, you make an excellent point and one that companies need to really be aware of.  One of the problems with any new topic, such as PCI, is that the volume of information can be overwhelming.  </p>
<p>When small startups try to direct the details and differences between: PCI DSS, PCI PIN, and PCI PA-DSS it can be overwhelming.  Throw in acronyms such as DSE, ISO, TPP, and people just stop listening.</p>
<p>That is why it&#8217;s very important that we digest the information for our target audience.  I&#8217;ve taught the information to large and small companies alike in various industries, and each constituent has a different take home message pertinent to they way they do business.</p>
<p>If there is one take home message I would have for your audience it&#8217;s that PCI only applies to you if you &#8220;store, process, or transmit cardholder data.&#8221;  Now I don&#8217;t have to even define cardholder data before you ask how to get this compliance monkey off your back.</p>
<p>It&#8217;s simple, just don&#8217;t ever store, process, or transmit cardholder data &#8211; let someone else do it for you.  In reviewing a shopping cart recently they had two modes of operation:</p>
<p>1) Solutions that don&#8217;t require customers to redirect<br />
2) Systems that redirect your customers to a payment site and then back</p>
<p>Small startups want to choose number two because it causes the end user to enter their credit card data at the third-party vendor, instead of accepting it themselves.  Even if they only accept it for a second on their one web server, now that server is in scope for PCI compliance.</p>
<p>So, want to do away with PCI?  Don&#8217;t accept cardholder data online, and let someone else do it for you.</p>
<p>But what if a governing body asks me to validate compliance, or provide them a report stating we are doing everything right?  Well, you can confidently fill out the Self-Assessment Questionnaire (SAQ) A.  This means you only do card-not-present transactions and all Cardholder Data functions are outsourced.  This is only 11 questions, instead of the 224 question long SAQ D (they are labeled A, B, C, and D.)</p>
]]></content:encoded>
	</item>
</channel>
</rss>
