Skip to main content

Tokenized Encryption: Connecting Docs


This third and final article on documentation examines the information necessary to support a cryptographic interface oriented to CICS Transaction Server and MVS. While the focus is on mainframe environments, the principles and concepts apply to all IT systems. Likewise, except for specific programming languages and software, this information applies to all platforms. Function and implementation may vary.

The first article introduces PCI compliance documentation, a mandatory, vital component due to the plethora of forms that must be created and maintained. Though it's seen as a tedious task, documentation is critical. It's especially helpful to new or inexperienced employees or contractors. Partly because it’s reviewed in a PCI audit, and partly because it’s the glue that keeps PCI compliance infrastructure and function operational, first rate documentation is extensive and detailed. Well-written documentation eliminates time spent in research, testing, and investigation during breaches and outages as well as normal activities, and in the case of a PCI Compliance implementation, simplifies and assures the security of cardholder data (CHD), checking account data (CAD) and social security number (SSN).

The remainder of the first article covers the Cryptographic and PCI Compliance Interface (CPCICI) User’s Guide structure and its first four sections.

The second article focuses solely on section five, which is devoted to error handling, coding considerations, programming guidelines and suggestions, sample code, copy books, and various programming tips. It also discusses underlying error handling methodology while providing a list of software product messages (z/OS, CICS TS, ICSF, etc.) built into copy books, as well as guidance on how to construct user messages. A comprehensive error handling architecture is vital to the PCI compliance implementation.

This article delineates section six, Compendium of PCI Compliance Documentation. The notions of compendium and document server are important ones. A compendium is more than just a table of contents, and it’s different than abstracts; these were designed to describe a document’s utility and illuminate what a document was to be used for. A document server provides multiple advantages: thorough and comprehensive security, quick and easy access, search and display capabilities, customizable print and download utilities, even Q&A facilities. Section six’s primary purposes are twofold:

  1. Provide information on PCI compliance and internal programming documents. These documents not only have names, but often alphanumeric identifiers of Category, Requirement and Sub-Requirement number. Using those identifiers as secondary document names simplified the PCI compliance audit.
  2. The description included links to the current version of a specific document. Anyone who needed document access needed only to click on it. If it was secured, a signon was required. Public documents immediately came up. Some CPCICI User’s Guide links were for general programming topics; those links went to local document servers on client premises.

All PCI compliance documents—and as time passed, numerous other IT documents—were stored on a document server accessible to IT staff, PCI compliance auditors and staff, and members of the mainframe service provider’s staff. The document server was owned, administered and managed by an accredited third party, and security authorizations and standards were strictly defined and enforced. Specific procedures had to be followed and approvals were needed to move or access documents.

User’s Guide, Compliance and Documentation

PCI compliance documents had a specific, mandatory header format at the beginning of each document, and many documents were reviewed as part of the annual PCI compliance audit. Documents needing review were determined in the audit’s initial step. Review and completion of a PCI audit checklist that identified requirements that had changed during the prior year or were an annual imperative. All documents related to PCI compliance standards had to be reviewed annually; if no changes had been made, only the date of most recent review had to be updated. Templates, samples and guidelines were provided in PCI Data Security Standard (DSS) documentation regarding how specific documents should be structured. Here’s how most document headings were structured.

Document title – A name that describes a document’s purpose and includes PCI requirement and sub-requirement where appropriate.

Document description – A relatively detailed explanation of the document’s subject. For example, “This document identifies the specific steps that must be taken in order to create a new private encryption key for use in encryption, decryption, and other cryptographic functions that are performed by all online and batch systems on the mainframe.”

Document owner – Initially the document author, but over time, either the last person who modified the document or the person who replaced the originator in the case of departure or reassignment.

Document type – Documents can take the form of written material, audio, video, or audiovisual media, or forms of media.

Document category – Many document types can exist in a document library. Here are some common ones:

  • Procedures
  • Blank forms
  • Standards & Guidelines
  • Reports & Listings
  • Checklists
  • References
  • Guides
  • How-to Charts
  • Specifications
  • Q&As Archives
  • Project Plans
  • Questionnaires
  • Cheat Sheets Books
  • Tutorials
  • Charts
  • Vendor Manuals Benchmarks
  • Internet Sources

Date of creation – Year, month, day and time when a document was first completed, approved, authorized and posted to the document server.

Date of most recent review – Year, month, day and time that a document was modified or officially reviewed by a PCI compliance enforcement unit member.

Most recent modifications – Any document modifications are recorded in a Modifications section at the document’s cover page. An addition’s text―or before and after versions of a revision’s text―are listed, along with an explanation. Large changes are noted here, and actual text is placed at the document’s last page.

Specific extracts – Sometimes it’s desirable to post only a portion of a large document (such as a chapter of a book), both for reasons of simplicity and storage savings, with a link to the full document in the Internet.

Here are some examples of document grouping and the sort of documents within them. Listing by group is the way the compendium was organized:


  • Private encryption key generation
  • Public encryption keys generation
  • Public encryption keys distribution
  • Private encryption key cutover (mainframe sensitive data)
  • Mainframe sensitive data cutover
  • Distributed sensitive data cutover
  • Public encryption key cutover (distributed sensitive data)
  • Load balancing test and tuning

Standards and Guidelines

  • IT Programming Standards
  • PCI Programming Standards
  • PCI Compliance Programming Guidelines
  • Transaction Error Handling Guidelines for PCI

Checklists and Cheat Sheets

  • Items to specify or verify regarding a PCI compliance-related change
  • Tests to run to verify error handling works as specified


  • Company Security Guide for employee validation, verification, definition, and tracking
  • CICS TS Application Programming Guide
  • RACF Security Guide
  • Encryption keys – management, definition, and maintenance

Project Plans

  • PCI Compliance Tasks.
  • PCI Compliance Conversion and Migration Plan
  • ePay Tasks
  • ePay Conversion Plan

Blank forms

Reports and Listings

  • Signon logs
  • Signon violation logs
  • Unauthorized file access attempts
  • Sensitive data content logs
  • ICSF Mega-Cryption Benchmark


  • Past PCI Compliance audit assessments and results
  • Past signon and token file access logs
  • Past security violation logs

Training Manuals

  • Application Programming Orientation
  • Secure Coding Questions

Issue Breach Notifications

For documentation of all varieties and types, but especially PCI compliance-related documentation, it’s vital that documentation be highly secured and easily accessible. The Compendium of PCI Compliance and IT Documentation endeavored to do that in two different ways:

Documentation―the carrier of information―is one of IT’s most valuable and indispensible assets, a fact that’s true for all facets of most enterprises. In this age of electronic ubiquity, information is the fuel that fires the engine.

  1. Provide descriptive text that helped a viewer to easily find the documentation they need
  2. Provide quick and easy access to that documentation