私は毎週紙の小切手による寄付をたくさん受け取るNPOで働いています。寄付を記録する現在のプロセスは退屈で、主に紙の上で行われます。ほとんどの寄付は通常の寄付者からのものであるため、私たちは一意の寄付者IDを割り当てます。これにより、年末の寄付レポート(寄付者は税務目的で使用できます)を簡単に作成できます。ただし、ほとんどの寄付者は小切手に寄付者IDを書き込まないため、各寄付者IDを手動で検索する必要があります。
このプロセスを合理化するために、社内で使用する小さなC#デスクトップアプリを開発しています。私が提供したい機能の1つは、ドナーIDの迅速な検索です。可能な実装は、MICRリーダーを使用して小切手をスキャンすることです。これにより、ドナーのABAルーティングとアカウント番号が取得されます。実際のところ、その情報は必要ありませんが、ドナーのIDをすばやく検索するために使用できます。ルーティング番号とアカウント番号を連結し、SHA-512のようなものでハッシュしてから、これらのハッシュをドナーIDに関連付けるテーブルに格納できます。
これらの一方向ハッシュルーティング/アカウント番号はPCIデータと見なされるため、PCI DSS私たちのオフィスのコンプライアンスが必要ですか?
注:この投稿に関係のない理由により、これらの小切手をEFTに変換することはできません。これは私の個人的な好みです。
このテーマについて説明している次の質問を読むことをお勧めします。 アカウント番号とソートコードをオンラインで保存する
つまり、アカウントの詳細を保存する場合PCIは適用されません;支払いカードにのみ適用されます。ただし、この標準は依然として、安全なデータを格納するための最も受け入れられている標準の1つを提供しています。そのため、PCIは、優れた実践に役立つ参照ポイントです。
PCI標準を確認し、関連するすべての推奨事項を実装することをお勧めします。ただし、支払いカードを扱っていないため、準拠するための法的要件はありません。
規格の関連セクションは、7ページの PCI DSS v3.1 から始まります。これにより、機密と見なされるデータが識別されます。
PCIスキームの主催者がこのスキームの適用範囲を可能な限り広くしたことは注目に値します。これは意図的なものでした。したがって、簡単な答えは、機密のカード所有者または認証データを処理する場合、スキームが適用されます。
このスキームの背後にある意図は、機密のカード所有者/認証データが存在する場合は常に、そのデータに基本レベルの保護を提供することです。このため、どのような場合でもこのスキームを実装するのにコストがかかりすぎてはなりません。
この場合も、このようなスキームは、想定されているほど単純ではありません。
ハッシュ化された情報の保存は、単にスキームへの準拠の一部であり、準拠を回避する手段ではありません。ハッシュデータストレージは、データストレージ要件に準拠するための手段となります(下の表を参照)。
ただし、残りのスキーム(ネットワークトポロジ、PCセキュリティなど)への準拠は、情報の格納方法には依存しません。