DIG Book PI Web

PepsiCo
<TITLE PLACEHOLDER>
Digital Interactive Group
Introduction to the Playbook

INTRODUCTION
DRAFT - February 23, 2011

introduction to the DIG Book
Description ...................................................................... 1.1.3

contents A new digital playing field ............................................................................................ 1.1.3
Detail .............................................................................. 1.1.5

How to take the lead in the digital game ..................................................................... 1.1.5
Staying grounded as the game changes ..................................................................... 1.1.6
Where to start.............................................................................................................. 1.1.7
© 2011 PepsiCo Inc.
1.1.2 DIGITAL INITIATIVES GUIDEBOOK October 2011

Internal Use Only
Description A new digital playing field

description The increase in digital channels creates exciting and dynamic
opportunities for PepsiCo and the markets we serve. As web, mobile,
and social channels become the dominant interface in engaging,
dialoging, and conducting business with consumers, the demands of
ensuring a consistent consumer experience, protecting brand
reputation, and ensuring speed-to-market have become
increasingly difficult.
As a company, PepsiCo must take swift, decisive action when seeking to innovate, and also
manage the risk that is inherent with innovation. The ever changing digital playing field and
our increased participation in that field require a greater level of collaboration and project
discipline among our partner agencies and vendors and our own functional teams, including
brand, procurement, legal and IT. To that end, we have built process activities, standards,
and checklists to ensure success for PepsiCo digital projects.
October 2011 DIGITAL INITIATIVES GUIDEBOOK 1.1.3

Internal Use Only
PepsiCo digital initiative: single view

Internal Use Only
Detail How to take the lead in the digital game

We have built a unified approach to technology by streamlining the multiple strategic control
detail points within our company (i.e. data capture, analytics, etc.). All project stakeholders
(agencies, vendors, and PepsiCo functional teams) share these processes and standards
and help strengthen the organization by becoming well equipped to deal with the
performance variability and speed inherent in the digital space.
By pursuing best-practices and harnessing historical data from each digital project, we can
apply knowledge to our organization’s most pressing strategic and tactical challenges. Our
goals are to have this new approach become one of many platforms that can help socialize,
in real-time, the knowledge that exists within every digital project and build a continuous
improvement process that will place PepsiCo as a digital leader, and our partner agencies
and vendors at the cutting edge of service delivery.

Internal Use Only
Staying grounded as the game changes

The Digital Initiatives Guidebook (the DIG Book) provides an overview to the processes,
procedures, business standards, and checklists necessary for shepherding digital projects
through the PepsiCo organization and into the market.
The DIG Book guides agencies and PepsiCo brand, procurement, legal, and IT functions to
analyze the technical viability of projects by answering questions such as: a) Will the project
be considered high risk?; b) Will data be captured consistently and with the correct security
measures in place?; and c) Are common protocols in place to share data or assets between
multiple 3rd party providers?
The DIG Book is based on PepsiCo’s most highly-complex web projects. It is comprised of a
series of main sections and multiple subsections describing a process that may apply in a
continuous cycle or as stand-alone activities for a project. Many activities are highly
interdependent (web process + web certification).
Low to medium complexity digital projects will be able to utilize the same process by
tailoring the approach and activities without losing an Agency’s core methodology or
process.

Internal Use Only
Where to start
The DIG Book accommodates all project types: large or small, short or long, iterative or
waterfall. The processes are applicable to all PepsiCo web, mobile, social and campaign
projects. Determining which processes or activities are required is based on our Risk
Assessment and Process Tailoring Tool. The tool is a quick and efficient way to measure
project risk and complexity and to determine what activities need to be “tailored” to meet
new standards and guidelines.
Every activity in the DIG Book is also a project milestone which has specific tasks for the
PepsiCo teams and identifies the required support from the agency. As the risk and
complexity of a project lowers, the number of activities will lower for the agency. However,
the PepsiCo activities will remain stable for all projects to ensure compliance to a unified
technology approach for all digital projects.
The process begins with Agency Certification and Onboarding; new agencies and vendors
and existing agencies and vendors become certified by submitting our Technology
Capabilities Assessment questionnaire. Once qualified for a specific project or service, an
agency or vendor moves on to technical onboarding where they learn about new process
activities from our IT team (Business + Information Solutions, or “BIS”), and how to interface
with the risk tool, new standards, and other areas.
After onboarding, agencies and vendors begin their project with a brand team and an
assigned BIS digital interactive specialist. From ideation and through the project lifecycle,
the digital interactive specialist will be the shepherd of the project as well as the facilitator in
assisting with new documentation and requirements.

Internal Use Only

Internal Use Only
<TITLE PLACEHOLDER>
PepsiCo
Technology Capabilities
Assessment for Digital Projects
(Web, Mobile, Email and Social)
AGENCY CERTIFICATION

technology capabilities assessment
Objective ......................................................................... 2.1.4

contents Process ........................................................................... 2.1.5
Project information .......................................................... 2.1.6
Information required - overview ................................................................................... 2.1.7
Approvals .................................................................................................................... 2.1.7
Contact information - example .................................................................................... 2.1.9
Project approach & processes: general .................................................................... 2.1.10
Test methodology: general ........................................................................................ 2.1.11
Project approach & processes: websites .................................................................. 2.1.11
Platforms & standards: websites ............................................................................... 2.1.12
Warranty & support: websites ................................................................................... 2.1.13
Data security & transfer protocols: websites ............................................................. 2.1.13
Database & data collection process and procedures: websites ................................ 2.1.14
Content management: websites ................................................................................ 2.1.16
Usability: websites..................................................................................................... 2.1.16
Other information: websites ...................................................................................... 2.1.17
Project approach & processes: mobile ...................................................................... 2.1.20

Internal Use Only
Platforms & standards: mobile .................................................................................. 2.1.20
Testing methodology: mobile .................................................................................... 2.1.21
Warranty & support: mobile ....................................................................................... 2.1.22
Data security & transfer protocols: mobile ................................................................. 2.1.22
Database & data collection process and procedures: mobile .................................... 2.1.23
Project approach & processes: email ........................................................................ 2.1.24
Platform & standards: email ...................................................................................... 2.1.25
Testing methodology: email ...................................................................................... 2.1.25
Database & data collection process and procedures: email ...................................... 2.1.26
Usability: email .......................................................................................................... 2.1.27
Warranty & support: email ......................................................................................... 2.1.27
Project approach & processes: social ....................................................................... 2.1.28
Platforms & standards: social .................................................................................... 2.1.28
Database & data collection process and procedures: social ..................................... 2.1.29
Content management: social .................................................................................... 2.1.30
Usability: social ......................................................................................................... 2.1.30
Warranty & support: social ........................................................................................ 2.1.31
For PepsiCo-internal only .......................................................................................... 2.1.31
Online template............................................................ 2.1.32

Internal Use Only
Objective Through the Technology Capabilities Assessment, PepsiCo teams,

including brand, procurement, and Business + Information Solutions
objective (BIS), validate the technical capabilities of new and potential
agencies that have been identified to create, develop and deploy
digital projects for PepsiCo.
This assessment also serves as a gate check before a new agency or vendor is invited to
enter into the RFP process. In addition, this process will enable the BIS team to validate and
ensure the minimum technical requirements for “quick win” or pilot projects are present for
vendors who win business outside of the formal RFP process.
And finally, this assessment is also the first gate to enter the PepsiCo Agency and Vendor
Certification Program.
Proposed agency certification process (New Agency)

Internal Use Only
Process A BIS digital interactive specialist will work with a brand sponsor to
execute all processes and validate all documents. Once the
process Technology Capabilities Assessment has been completed by the
agency or vendor, the BIS team will review the submission and apply
a maturity score to all answers, using the Technical Capabilities
Assessment Scorecard and the maturity scoring key / legend.
Once a final maturity score is tallied, the BIS specialist, brand representative, and
procurement representative will meet to discuss the score and determine next steps.
An agency or vendor may score low in some areas and high in others. It will be a joint
decision if the agency or vendor is invited to enter into the RFP process. If technical
weaknesses (low maturity score) are considered low impact to the project, the
BIS specialist can identify these areas and ensure they are addressed during agency
and vendor onboarding.

Internal Use Only
project
Project Project name Launch date
information
information
Business partner
BIS digital
interactive specialist
Group
Agency
Notes

Internal Use Only
Information required - overview

BIS will work with the new agency to validate that the agency has completed documentation
to the level of detail necessary to approve technical capabilities. The supporting information
required includes:
 Project approach & processes: general *  Data security & transfer protocols: mobile
 Testing methodology: general *  Database & data collection process &
procedures: mobile
 Project approach & processes: websites
 Project approach & processes; email
 Platforms & standards: websites  Platforms & standards: email
 Warranty and support: websites  Testing methodology: email
 Data security & transfer protocols: website  Database & data collection process &
 Database & data collection processes: procedures: email
website  Content management: email
 Content management: website  Usability: email
 Warranty and support: email
 Usability: website
 Project approach & processes: social
 Other information: website
 Platforms & standards: social
 Project approach & processes: mobile  Database & data collection process &
 Platforms & standards: mobile procedures: social
 Testing methodology: mobile  Content management: social
 Usability: social
 Warranty and support: mobile
 Warranty and support: social
* must be completed for all submissions
Approvals
Your signature indicates your review and agreement with the content in this document and
that you are accountable for the sign-off of this completed key deliverable.Key deliverables
that require signature are under formal change control once they have been signed.

Internal Use Only
Deliverables Signature Req’d Date Signature Comments
Project approach & processes: general*
Test methodology: general*
Project approach & processes: websites
Platforms & standards: websites
Warranty and support: websites
Data security & transfer protocols: websites
Database & data collection process & procedures: websites
Content management: websites
Usability: websites
Other information: websites
Project approach & processes: mobile
Platform & standards: mobile
Testing methodology: mobile
Warranty and support: mobile
Data security & transfer protocols: mobile
Database & data collection process & procedures: mobile
Project approach & processes: email
Platforms & standards: email
Testing methodology: email
Database & data collection process & procedures: email
Content management: email
Usability: email
Warranty and support: email
Project approach & process: social
Platforms & standards: social
Database & data collection process & procedures: social
Content management: social
Usability: social
Warranty and support: social
*must be completed for all submissions

Internal Use Only
Contact information - example

Business partner sponsor
Business partner Randall Brown Position Digital Marketing Manager
Group QTG- Gatorade Telephone #
Email address Randall.brown@pepsico.com
BIS sponsor
BIS engagement mgr. Paul Longo Position BIS Manager
Group QTG - Gatorade Telephone #
Email address Paul.Longo@Pepsico.com
Agency contact 1
Agency contact name (1) Position
Group
Agency name
Address Telephone #
Email address
Agency contact 2
Agency contact name (2) Position
Group
Agency name
Address Telephone #
Email address

Internal Use Only
Project approach & processes: general

1. Describe the typical type of projects and development your firm is engaged in as your
primary business.
2. Describe the activities and stage details of a typical project (i.e. objective of activity,
work input, work output, roles, responsibilities, estimated time to complete by %). The
following activities are illustrative:
o Concepting
o Analysis and planning
o Requirements gathering and documentation
o Concept approval
o Sitemaps
o Wireframes (includes architectural decision making)
o Design & implementation
o Testing
o Analytics & reporting
o Performance & maintenance (periodic content updates, on-going of rich content
media, and iterative enhancements to web applications and framework).
3. What type of management reports does your firm provide to help manage the project?
Can reports be accessed real-time and directly by PepsiCo via a website or other
media provided by your agency?
4. Describe your firm‟s issue and escalation procedures.
5. Do you have a change control process? If YES, please describe.
6. Describe your firm's process and approach to cross vendor coordination.
7. What internal quality measures are in place for the following: a) Process Adherence; b)
Project Delivery; c) Personnel Performance and Delivery Standards.

Internal Use Only
Test methodology: general

8. Does your firm have a testing methodology? If YES, please explain what is included in
your testing methodology (e.g. system testing, integration testing, etc.)
9. Does your firm conduct all testing or do you use 3rd party contractors to perform
testing? If you use 3rd party contractors, please describe the process you use to
qualify these contractors.
10. What type of feedback mechanisms do you have in place to socialize test issues and
problems?
11. Describe your refinement process to keep your testing methodology concurrent with
new and developing technologies.
12. Do you have pre-defined "code freeze" procedures or do you rely on the client to;
define? Please explain
13. Do you use any tools to automate testing? If YES, please describe.
14. Describe the tools that are used for: a) defect management; b) performance testing;
and c) security testing.
Project approach & processes: websites

15. Please describe your firm‟s project approach and the processes used when creating,
developing and launching a website (e.g. waterfall process, iterative/agile process,
etc.).
16. Describe your firm‟s methodology and process for managing multi-region and global
asset development.

Internal Use Only
Platforms & standards: websites

17. What primary website platforms have you used in the last twelve (12) months? (e.g.,
JAVA, .Net, WebSphere, etc.). Please describe platform of preference and why.
18. How many FTE are trained on each of the technologies cited above?
19. If your firm uses off-shore delivery partners or third party vendors for website creation
and development, please explain your company vendor‟s capabilities related to the
primary website platforms listed above.
20. If your firm uses off-shore delivery partners or third party vendors for website creation
and development, describe your firm‟s policies and procedures in managing offsite
developers used on projects.
21. Please describe the type of supporting web applications you have used in the last
twelve (12) months and cite the technology and/or vendor (e.g., Facebook connect,
site search, live chat, reviews & forums, email, web analytics, web content
management, rich media, search engine marketing, etc.).
22. What methods or application(s) do you use for code maintenance and version control?
23. How does your firm ensure that a website is configured for maximum performance?
(i.e., search optimization, page downloads, reduced load times, enhanced customer
experience, increased functionality).
24. Does your firm have techniques for implementing and testing accessibility for websites
and web applications? If YES, please describe (Referencing Information and
Communication Technology Accessibility Standards in Section 508 of the U.S. Federal
Rehabilitation Act and the World Wide Web Consortium‟s (W3C) Web Content
Accessibility Guidelines (**WCAG 2.0).

Internal Use Only
25. Please describe how your firm assists clients in complying with the Children‟s Online
Privacy Protection Act (COPPA) as it relates to website and on-line services directed to
children under 13 and collecting personal information.
26. Please describe your process for DNS registration and management.
Warranty & support: websites

27. What period of time does your company typically warrant code?
28. What are the available support level agreement options in terms of type, cost, and
levels of service?
Data security & transfer protocols: websites

29. What methods are used when secure data is being transmitted between
organizations? (i.e., what types of encryption protocols are in use and for what type of
data?)
30. Do you have a data destruction policy? If YES, please describe.
31. Please describe how you handle opt in and opt out files. If you have a Preference
Management Strategy, please describe.
32. Please describe your firm‟s process for the following in-bound data errors: a) receipt of
unexpected data format; b) unmatched data elements; c) wrong file extensions; and d)
unexpected frequency
33. Do you have an automated process for data archiving? If YES, please describe.
34. How is data archived?
35. Where is data archived?

Internal Use Only
36. How is secure data encrypted within the database?
37. Application functions related to authentication and session management are often not
implemented correctly, allowing attackers to compromise passwords, keys, session
tokens, or exploit other implementation flaws to assume other users‟ identities. Please
describe your firm‟s process and implementation methods for secure authentication
and what steps you take to protect user identities.
38. Describe the guidelines and process your firm uses for session management and
maintenance.
39. Many web applications check URL access rights before rendering protected links and
buttons. However, applications need to perform similar access control checks when
these pages are accessed, or attackers will be able to forge URLs to access these
hidden pages anyway. Please describe your firm‟s authorization process and
standards for secure authorization.
40. Describe, if any, the tools and process your firm uses to prevent XXS attacks.
41. List the algorithm specifications your firm uses to ensure strong cryptography in order
to protect confidentiality and integrity of sensitive data.
Database & data collection process and procedures:

websites
42. What database platforms has your firm used in the last twelve (12) months?
43. Describe your process of collecting consumer data at time of site registration.
44. Describe your process when collecting customer data at the time of polling, voting
and/or surveys.

Internal Use Only
45. Do you have the ability to segment, real-time, by key need states? (e.g., prize or
sweepstake value, abundant value, quality value, etc.). If YES, please describe your
process.
46. Describe your process of hosting cleansing, maintaining and conducting pulls from a
segmented database.
47. Describe your methodology (process) for database capacity planning and proper sizing
and user configuration.
48. Please describe your process of handling promotional data (maintenance and
archiving).
49. List all marketing and campaign management platforms your firm has integrated
collected data with over the past 12 months. (e.g., CRM (Salesforce.com), Analytics
Platforms (Omniture), and/or EMM/Campaign Platforms (Unica).
50. Describe your firm‟s methodology and process for managing data collected in a multi-
region and/or global asset development.
51. Describe your methodology and processes for data backup and storage (focusing on
ensuring data integrity and security).

Internal Use Only
Content management: websites

52. Do you have a process and approach to centralized web content into a manageable,
searchable repository? If YES, please describe.
53. What specific tactics do you use to allow user to easily broaden or narrow searches?
54. Do you have a tool or process for approving and publishing content? If YES, please
describe.
55. List all open sources and licensed Content Management Systems your firm has
worked with over the past 12 months.
56. For the CMS solutions your firm typically interfaces with, what are your firm‟s
capabilities in expanding out of the box functionality? How many FTE of your firm are
focused on developing on these systems?
Usability: websites
57. PepsiCo is looking to improve the usability and functionality of their websites. Describe
how your firm approaches usability and optimizes functionality.
58. What differentiates you from the competition when it comes to information
architecture?
59. How many staff members are considered experts in information architecture and what
are their typical qualifications/experience levels?

Internal Use Only
Other information: websites

60. Describe the hierarchy of support recommended to meet the goals and requirements of
the creation and development of a website. Include the relative background of the
individuals and their responsibilities as well as organization charts.
61. Does your client list include companies who would be considered competitors of
PepsiCo. If so, please identify. Product categories include but are not limited to: a)
sport beverages‟ b) carbonated beverages‟ c) Snack Foods; d) Breakfast Foods; e)
Breakfast Beverages.
62. Does your firm provide web analytics? If YES, please describe the tools, reporting
formats, frequency and KPI/Measurements you are able to provide.
63. Describe the process and KPI measures used to ensure website performance,
recovery and availability.
64. Provide stats on up to four (4) high traffic websites which you have developed in the
last twelve (12) months and currently maintain.
65. Describe you firm‟s website hosting capabilities. Please list dedicated and shared
hosting options in relation to type, cost, and levels of service.
66. In terms of hosting, how does your firm view/guarantee site uptime and avoid outages
due to volume?
Live website „development‟ samples. Please list only live samples of projects that your firm
did the development for (note – not creative execution only).

Internal Use Only
Website #1
URL:
Activity Statistics
Number of registered users
Visits per day
Page views per day (average)
Page load times (average)

Concurrent users during load testing (if
available)
Website #2
URL:
Activity Statistics
Visits per day

available)

Internal Use Only
Website #3
URL:
Activity Statistics
Visits per day

available)
Website #4
URL:
Activity Statistics
Visits per day

available)

Internal Use Only
Project approach & processes: mobile

67. Have you developed mobile versions of a website? If YES, please describe your firm‟s
project approach and the processes used when creating, developing and launching a
mobile campaign and/or application. Please include the browser and OS versions
supported for the listed examples.
68. Describe how your firm validates suggested browser and OS version priority setting
decisions for projects.
69. Describe the activities and stage details of a typical mobile website deployment (i.e.
objective of activity, work input, work output, roles, responsibilities, estimated time to
complete by %).
70. Have you developed a mobile text campaign before? If YES, please describe your
firm‟s project approach and the processes used when creating, developing and
launching a mobile campaign and/or application.
asset development.
Platforms & standards: mobile

72. Has your firm developed native iPhone applications? If YES, please describe the
application and the target market.
73. Has your firm developed iPhone web applications? If YES, please describe application
and the target market.
74. Has your firm developed hybrid (native/web) applications? If YES, please describe the
75. Has your firm developed native Android applications? If YES, please describe the

Internal Use Only
76. If you have published applications to the Apple App Store and/or the Android Market,
please describe your process for handling client developed applications through the
process and post launch with regard to testing and managing ongoing
updates/revisions.
77. What presentation languages do you support? Please describe.
78. Describe how your developers handle instances where device functionality may be
limited (i.e. GPS is disabled or a device does not have a camera).
79. Describe your approach to domain allocation.
80. Does your firm support more advanced navigation methods for higher-end phones? If
YES, please describe.
81. Has your firm worked with 3rd party mobile advertising networks and/or integrated
advertising solutions into mobile applications? Please list advertising networks your
firm has worked with (e.g. AdMob, etc.)
Testing methodology: mobile

82. Does your firm have a testing methodology for mobile? If YES, please explain what is
included in your testing methodology.
83. Does your firm conduct all testing or do you use 3rd party contractors to perform
testing? If you use 3rd party contractors, please describe the process you use to
qualify these contractors.
84. What type of feedback mechanisms are in place to socialize test issues and problems?
85. Describe your refinement process to keep your testing methodology concurrent with
new and developing mobile platforms
86. Do you use any tools to automate mobile testing? If YES, please describe.

Internal Use Only
Warranty & support: mobile

87. Does your firm use any proprietary coding methodologies that would prevent our
company from handling ongoing maintenance, support, and enhancement of the
assets? If so, please describe reasoning and possible advantages gained by its use.
levels of service?
Data security & transfer protocols: mobile

90. What methods are used when secure data is being transmitted between
organizations? (i.e., what types of encryption protocols are in use and for what type of
data?
91. Do you have a data destruction policy? If YES, please describe.
92. Please describe how you handle opt in and opt out files. If you have a Preference
Management Strategy, please describe.
93. Please describe your firm‟s process for the following in-bound data errors: a) receipt of
unexpected data format; b) unmatched data elements; c) wrong file extensions; and d)
unexpected frequency.
94. Do you have an automated process for data archiving? If YES, please describe.
95. How is data archived?
96. Where is data archived?
97. How is secure data encrypted within the database?

Internal Use Only
98. Application functions related to authentication and session management are often not
implemented correctly, allowing attackers to compromise passwords, keys, session
tokens, or exploit other implementation flaws to assume other users‟ identities. Please
describe your firm‟s process and implementation methods for secure authentication
and what steps you take to protect user identities.
99. Describe the guidelines and process your firm uses for session management and
maintenance.
100. List the algorithm specifications your firm uses to ensure strong cryptography in order
to protect confidentiality and integrity of sensitive data.

mobile
101. What mobile application database platforms/solutions has your firm used in the last
twelve (12) months?
102. Describe your process of collecting consumer data at time of application registration.
and/or surveys.
104. Do you have the ability to segment, real-time, by key need states? ( e.g., prize or
process.
segmented database.
107. Describe your process of handling promotional data (maintenance and archiving).

Internal Use Only
collected mobile subscriber data with over the past 12 months. (e.g., CRM
(Salesforce.com), Analytics Platforms (Omniture), and/or EMM/Campaign Platforms
(Unica).
Project approach & processes: email

111. Please describe your firm‟s project approach and the processes used when creating,
developing and launching an email campaign (i.e. one-time, recurring, event-triggered,
sequenced, etc.)
112. Describe the activities and stage details of a typical email campaign (i.e. objective of
activity, work input, work output, roles, responsibilities, estimated time to complete by %).
113. Does your firm adhere to CAN-SPAM requirements? If YES, please explain.
114. Please detail your firms email guidelines and standards for: a) broadcast format b)
HTML; c) images; d) tables; e) style sheets; f) layers; and g) multi-media content.
115. What type of reporting and measurements do you provide during and post an email
campaign? Describe your firm‟s ability to track deliverability and responses and real-
time.

Internal Use Only
116. Does your firm have the ability to standardize and fix address errors? If yes, please
describe.
117. Does your firm have the ability to screen for vulgarity and/or profanity within an email
address? If YES, please describe.
118. Does your firm host the email platform? If YES, please describe your firm‟s white lists
process.
119. What is your firm‟s process and procedures for permission management?
120. Describe your firm‟s methodology and process for managing multi-region and
global asset development.
Platform & standards: email

121. Describe your firm‟s email platform and its capabilities. Please explain solution options
(e.g. hosted or SAS), costs (especially related to distribution pricing), and levels of
service.
122. Do you have the ability to integrate with content managements systems and/or
consumer database? If YES, please explain.
Testing methodology: email

123. Does your firm have a testing methodology for email campaigns? If YES, please
explain what is included in your testing methodology, particularly the development of
control groups.
124. Does your firm have a “science” developed for subject line creation? If YES, please
describe.

Internal Use Only

email
125. What mobile application database platforms/solutions has your firm used in the last
twelve (12) months?
126. Describe your process of collecting consumer data at time of application registration.
and/or surveys.
process.
segmented database.
archiving).
collected mobile subscriber data with over the past 12 months. (e.g., CRM
(Salesforce.com), Analytics Platforms (Omniture), and/or EMM/Campaign Platforms
(Unica).

Internal Use Only
Usability: email
135. PepsiCo is looking to improve the usability and functionality of their websites. Describe
how your firm approaches usability and optimizes functionality.
136. What differentiates you from the competition when it comes to information
architecture?
Warranty & support: email

138. Does your firm use any proprietary coding methodologies that would prevent our
company from handling ongoing maintenance, support, and enhancement of the
assets? If so, please describe reasoning and possible advantages gained by its use.
levels of service?

Internal Use Only
Project approach & processes: social

141. Describe your firm‟s capabilities in social media application development and/or social
media campaigning.
142. How many FTE‟s do you currently have developing social applications/campaigns?
Please list by social platform or solution. If possible provide a capabilities breakdown
by percentage (e.g. 30% resources focused on strategy, 40% development, 15%
delivery/test, etc.)
social media application/campaign asset development.
Platforms & standards: social

144. What primary social site platforms have you developed substantial strategy, content,
and developed applications/assets on in the last twelve (12) months? (e.g., Facebook,
Youtube, Twitter, LinkedIn, Slideshare, Myspace, etc.). Please describe platform of
preference and why.
145. How many FTE are trained on each of the technologies cited above?
146. If your firm uses off-shore delivery partners or third party vendors for asset creation
and development, please explain your company vendor‟s capabilities related to the
primary website platforms listed above.
147. If your firm uses off-shore delivery partners or third party vendors for asset creation
and development, describe your firm‟s policies and procedures in managing offsite
developers used on projects.

Internal Use Only

social
148. What database platforms has your firm used in the last twelve (12) months specifically
related to social media applications, assets, and campaigns?
149. Describe your process of collecting consumer data at time of registration.
process.
segmented database.
archiving).
collected data with over the past 12 months. (e.g., CRM (Salesforce.com), Analytics
Platforms (Omniture), and/or EMM/Campaign Platforms (Unica).

Internal Use Only
Content management: social

157. Do you have a process and approach to centralized social content into a manageable,
searchable repository? If YES, please describe.
158. Do you have a tool or process for approving and publishing content? If YES, please
describe.
159. List all open-source and licensed Content Management Systems your firm has worked
with over the past 12 months.
160. For the CMS solutions your firm typically interfaces with, what are your firms
capabilities in expanding out of the box functionality related to social media features?
How many FTE of your firm are focused on developing on these systems.
Usability: social
161. PepsiCo is looking to improve the usability and functionality of their web assets.
Describe how your firm approaches usability and optimizes functionality.
162. What differentiates you from the competition when it comes to information architecture
in social applications/campaigns?

Internal Use Only
Warranty & support: social

levels of service?
For PepsiCo-internal only

To be completed by PepsiCo Business Partner Sponsor after document completion by
potential vendor.
1. What is the primary reason for submitting vendor for certification? (e.g., project
description, RFP reference #, or skill specialty).
2. In your view, what does this vendor bring to the table that existing vendors may not be
as well suited for?
3. Do you have any additional information to provide in regard to this potential vendor?

Internal Use Only
Template See the Technology Capabilities Assessment online template on PepsiCo‟s Agency
online Portal under the Forms, Tools & Reference section.
template

Internal Use Only
<TITLE
agency/vendor certification flowchart
Certification part 1........................................................... 2.2.3

contents Certification part 2........................................................... 2.2.4
Activity map .................................................................... 2.2.5

Internal Use Only
New Agency & Vendor Certification Part 1

Internal Use Only
New Agency & Vendor Certification Part 2

Internal Use Only
Activity map The Agency Certification Activity Map is a Microsoft Excel online tool with additional
agency certification details for PepsiCo project teams. Refer to the Digital Resource
activity map Center under the Forms, Tools & Reference section.
Path: www.mypepsico.com > My Groups tab > PepsiCo-wide > Digital Resource Center

Internal Use Only

Internal Use Only
<TITLE PLACEHOLDER>
PepsiCo
Onboard with PepsiCo

Agency Onboarding

onboard with PepsiCo
Objective ......................................................................... 3.1.3

contents Process ....................................................................................................................... 3.1.3
About PepsiCo ................................................................ 3.1.4

PepsiCo at a glance .................................................................................................... 3.1.4
Our operations ............................................................................................................ 3.1.4
Performance with purpose .......................................................................................... 3.1.5
Your role ..................................................................................................................... 3.1.5
About PepsiCo BIS ......................................................... 3.1.6

BIS vision .................................................................................................................... 3.1.6
BIS focus ..................................................................................................................... 3.1.7
Appendix......................................................................... 3.1.8

Internal Use Only
Objective Congratulations for being selected by our team at PepsiCo. We look

forward to building a long-lasting and mutually beneficial relationship
objective with your firm. We are sure that this is an important milestone for
your organization and we are very interested in making it a success.
The onboarding document serves as a broad introduction to PepsiCo and PepsiCo’s IT
function, Business + Information Solutions (BIS). It highlights BIS goals, objectives,
responsibilities, and relevant logistical information.
Process
By now, your BIS onboarding contact has been in touch with you to introduce your team to
the BIS technical onboarding process and to schedule the onboarding session. Additional
information will be provided during the onboarding session, however, the following sections
should help jumpstart your understanding of our department’s responsibilities, organization,
and capabilities.
Please let your BIS onboarding contact know if you have any questions or comments in
advance of the upcoming sessions.

Internal Use Only
About PepsiCo at a glance

about
Pepsico PepsiCo offers the world’s largest portfolio of billion-dollar food and beverage brands,
PepsiCo including 19 different product lines that generate more than $1 billion in annual retail sales
each. Our main businesses – Frito-Lay, Quaker, Pepsi-Cola, Tropicana, and Gatorade –
also make hundreds of other nourishing, tasty foods and drinks that bring joy to our
consumers in over 200 countries.
PepsiCo strives to continually improve all aspects of the world in which we operate -
environmental, social, economic - creating a better tomorrow than today. Our vision is put
into action through programs and a focus on environmental stewardship, activities to benefit
society, and a commitment to build shareholder value by making PepsiCo a truly
sustainable company.
Our operations
PepsiCo is organized into three business units, as follows:
1. PepsiCo Americas Foods (PAF), which includes Frito-Lay North America (FLNA),
Quaker Foods North America (QFNA) and all of our Latin American food and snack
businesses (LAF), including our Sabritas and Gamesa businesses in Mexico;
2. PepsiCo Americas Beverages (PAB), which includes PepsiCo Beverages North
America and all of our Latin American beverage businesses; and
3. PepsiCo International (PI), which includes all PepsiCo business in Europe and all
PepsiCo businesses in Asia, Middle East and Africa (AMEA)

Internal Use Only
Performance with purpose

At PepsiCo, we're committed to achieving business and financial success while leaving a
positive imprint on society - delivering what we call Performance with Purpose. By
dedicating ourselves to offering a broad array of choices for healthy, convenient, and fun
nourishment, reducing our environmental impact, and fostering a diverse and inclusive
workplace culture, PepsiCo balances strong financial returns with giving back to our
communities worldwide.
Learn more about Performance with Purpose.
Your role
The digital world, like no other, can make a positive OR negative impact on the imprint
PepsiCo leaves on society. As a certified agency and vendor of PepsiCo, you are now an
important contributor to our corporate mission, working to assist us in continually making
improvement in all aspect of our digital projects. We look to you to help guide us and ensure
our brands deliver performance with purpose.

Internal Use Only
About BIS – Business + Information Solutions – is a global function of

aboutBIS
PepsiCo
skilled and knowledgeable experts bringing world-class, locally
relevant business capabilities and powerful solutions to drive
PepsiCo BIS
competitive advantages.
BIS vision
To be the PepsiCo business capability engine: powering solutions through connection,
transformation and innovation.
Connect the PepsiCo ecosystem – our associates, suppliers, customers, stakeholders and
consumers to drive business growth.
Transform and leverage our information assets to scale solutions that create greater
competitive advantage.
Sustain the efficient, dependable, high-quality infrastructure so PepsiCo can drive

productivity and results.
Innovate with new technologies and services so you can do business smarter, faster,
greener and cheaper.

Internal Use Only
BIS focus
We are transforming our IT practices with:
 Thought leaders bringing new ideas to the business table
 Focus on a few big global ideas
 IT portfolio transformation
 Launch and leverage (especially One Up)
 Get close to retail customers
 Affordability through proof of concepts, prototypes, pilots, etc.
 True productivity bent on core operations
 Operating metrics gauge success
 Retrained IT teams

Internal Use Only
Appendix Optional documents

appendix Optional items that may be included with the Onboarding kit:
1. Annual Report and/or Legacy Book

2. Project team org chart/contact list
3. Most recent version of BIS Glossary and Acronyms doc
Other useful information to include as available is listed below.
Policies and procedures:
Key policies and procedures, Major ethics rules, Equal opportunity policy, Sexual
harassment policies, Civil rights, Whistleblower Act, Procurement, Human capital policies
and procedures, Organization holiday schedule, Parking, Security policies and procedures,
Key security policies, Sensitive security information,
Key work location information:
 Address of buildings – offices most accessed by agencies/vendors
 Building maps – offices most accessed by agency/vendors
 Driving, parking and public transportation directions – offices most accessed by

agencies/vendors
 Visitor process – offices most accessed by agencies/vendors
 Where key offices are located

Internal Use Only
<TITLE PLACEHOLDER>
PepsiCo
Data Privacy and Retention

STANDARD

website project flowchart
Planning phase ............................................................... 4.1.3

contents Designing and concepting .............................................. 4.1.4
Development phase ........................................................ 4.1.7
Launch phase ................................................................. 4.1.9
Post-launch phase ........................................................ 4.1.10
For PepsiCo-internal use only:
See the Process Activity Map – Web for additional process details.
The process activity map is a Microsoft Excel spreadsheet available on the
Digital Resource Center under the Forms, Tools & Reference section.
Path: www.mypepsico.com > My Groups tab > PepsiCo-wide > Digital Resource Center.

Internal Use Only

Internal Use Only

Internal Use Only

Internal Use Only

Internal Use Only

Internal Use Only

Internal Use Only

Internal Use Only

Internal Use Only
mobile app project flowchart
<TITLE PLACEHOLDER>
PepsiCo

STANDARD

Internal Use Only
Planning phase ............................................................... 4.2.3

Launch phase ................................................................. 4.2.9
See the Process Activity Map – Mobile for additional process details.

Internal Use Only

Internal Use Only

Internal Use Only

Internal Use Only

Internal Use Only

Internal Use Only

Internal Use Only

Internal Use Only

Internal Use Only
<TITLE PLACEHOLDER>
PepsiCo

STANDARD

social media project flowchart
Planning phase ............................................................... 4.3.3

Launch phase ............................................................... 4.3.11
See the Process Activity Map – Social for additional process details.

Internal Use Only

Internal Use Only

Internal Use Only

Internal Use Only

Internal Use Only

Internal Use Only

Internal Use Only

Internal Use Only

Internal Use Only

Internal Use Only

Internal Use Only
<TITLE PLACEHOLDER>
PepsiCo

STANDARD

campaign project flowchart
Planning phase ............................................................... 4.4.3

Launch phase ............................................................... 4.4.10
See the Process Activity Map – Campaign for additional process

details.


Internal Use Only

Internal Use Only

Internal Use Only

Internal Use Only

Internal Use Only

Internal Use Only

Internal Use Only

Internal Use Only

Internal Use Only

Internal Use Only

Internal Use Only
digital marketing metrics & KPIs
Objective ......................................................................... 5.1.4

contents Process ....................................................................................................................... 5.1.4
Project ............................................................................ 5.1.5

Project information ...................................................................................................... 5.1.5
Standard website metrics ............................................................................................ 5.1.6
Standard website KPIs ................................................................................................ 5.1.6
Common ......................................................................... 5.1.7

Content sites: subscription-based ............................................................................... 5.1.7
Customer service ........................................................................................................ 5.1.7
Commerce .................................................................................................................. 5.1.7
Lead generation .......................................................................................................... 5.1.8
Admin tool reports ....................................................................................................... 5.1.8
Customer reports ........................................................................................................ 5.1.9
Content group event.................................................................................................. 5.1.10
On-site search event ................................................................................................. 5.1.10
Scenario event .......................................................................................................... 5.1.10
Visitor record ............................................................................................................. 5.1.11

Internal Use Only
Social influence marketing (SIM) metrics .................................................................. 5.1.11

Blogs ......................................................................................................................... 5.1.12
Participate in social networks .................................................................................... 5.1.12
Website communities ................................................................................................ 5.1.13
Podcasts ................................................................................................................... 5.1.13
Ratings/reviews ......................................................................................................... 5.1.13
Widgets ..................................................................................................................... 5.1.14
Advertising in social networks ................................................................................... 5.1.14
Twitter ....................................................................................................................... 5.1.14
Facebook .................................................................................................................. 5.1.15
Mobile app metrics .................................................................................................... 5.1.16
Mobile analytics......................................................................................................... 5.1.17
Email - results ........................................................................................................... 5.1.18
Click rate benchmarks by slot ................................................................................... 5.1.18
Post-campaign survey findings ................................................................................. 5.1.19
Other metrics to consider .......................................................................................... 5.1.21

Internal Use Only
Objective This document will serve as a repository and reference guide to

catalog common Web, mobile, and social media metrics and key
objective performance indicators (KPIs).
This list is not intended to be exhaustive or prescriptive but is meant to serve as a guide to
charting out appropriate metrics for continued success and growth.
In addition, these KPI’s can bring measurement standardization across brands and
business units and begin to set a foundation for cross brand measurement.
Process
This list will be maintained by the PepsiCo Business + Information Solutions (BIS) digital
interactive team and updates will be made by the team and re-circulated. This list should be
modified and updated no less than once per operating quarter.
(NOTE: Please reference this document when creating KPI’s and metrics for the business
requirements document.)

Internal Use Only
Project Project information

project Project name Launch date
Business partner
BIS Digital
Interactive Specialist
Group
Agency
Notes

Internal Use Only
Standard website metrics

 Authenticated visitors  Searches per visit
 Unique visitors  Search Return visits
 Visits per month o Number of returning visitors
(based on cookies or a heuristic)
 Page impressions o Frequency of visit
 Clicks o Average order value
o Recency of visit
 Number of new visitors
 Visits under one minute
 Visit duration
Standard website KPIs

 Average of page views per visitor  Sales per visitor (gross sales/visitor)
 Average page views per visitor o Results found versus no results found
o Ratio of new to returning visitors
 Average number of visits per visitor o Stickiness
 Percent of visits (frequency x duration x site reach)
o Site reach (number of unique visitors
 Conversion
in a time period/total number of unique
(overall step and conversion)
visitors)
 Drivers to offline contact methods o Page exit ratio
 Cost per conversion (Page exits/Page visits)
(cost of campaign/conversion)
 On-site advertising click ratio

Internal Use Only
Common Content sites: subscription-based

common  Conversion of non-subscribers to subscribers
 Active subscriber base
 Average subscription length
 Renew conversion
 ROI based on conversion type
Customer service
 Average cost per service option (call center, email, online chat, self-service)
 Percent of support touches successfully served
 Drivers to other support methods from site
 Online search effectiveness (searches per visit, exit)
 Survey results/exit survey scores
Commerce
 Overall purchase conversion  Effect on offline sales
 Step-by-step conversion  First time versus returning buyer
behaviors, conversions, and revenue
 Average order size (AOS)
 Lifetime value
 Average order value (AOV)
 Affinity analysis (product and site)
 Analysis of purchase funnel defectors

Internal Use Only
Lead generation
 Overall conversion  Analysis of registration process
 Step-by-step conversion analysis dropouts
via registration process  Conversion of leads to actual customers
 Conversions by campaign  Value per lead based on conversion
 Drivers to registration process
Admin tool reports

 User first log-in  First-time versus returning visitors
 User last logged in  Average visit frequency & recency
 Number of log-ins  Searches per visit
 User guidance checkbox (tracking  Number of zero result queries
completion status of the first time user  Geography drilldown
guidance form as indicated by user)
 Offsite links
 Average views per visit
 Average visits per visitor

Internal Use Only
Customer reports
To help understand user behavior:
 Content groups (designate pages with related subject matter)
 Content group activity and history metrics
 Content group duration

(provide insight into which areas of the site are most attractive to visitors)
 Specialized conversion rates

(how many visitors are moving from one step to the next in a scenario)
o Scenario analysis (ex: product page viewed, product added to cart, checkout
started, checkout complete)
 Depth of exploration (ex: average page view per visit, length time, content
group exposure)
 Pages of interest
o Content group segmentation (metric)
o On-site search engines (metric)
o Collecting scenario events (metric)
o Visit-to-exit ratio (the number of exits from a given page to the number of visits
for the same page)

Internal Use Only
Content group event

 Content group event time
(segments visitors by the time that they viewed a content group)
 Content group name

(segments visitors by the name of the content group viewed)
 Content sub-group name

(segments visitors by the name of the of the content sub-group viewed)
On-site search event

 Search phrase (segments visitors by the search phrases visitors submitted)
Scenario event
Use to segment visitors who visit a page configured to track a step in a preconfigured
process – ex: registration.
 Conversion step (segments visitors by those who view a page defined as a scenario
conversion step)
 Scenario event time (segments visitors by the time that they visit a page defined as a
scenario step page)
 Scenario name (segments visitors by the name of the scenario they view)
 Step name (segments visitors by the scenario step they view)
 Step number (segments visitors by the scenario step they view)

Internal Use Only
Visitor record
Segment visitors by characteristics such as demographics:
 City  Metropolitan statistical area (MSA)
 State/province  Primary metropolitan statistical area
 Country (PMSA)
o Registered
 Designated marketing area (DMA)
o Time of lifetime initial Ad ID
 Lifetime initial ad ID o Time of lifetime initial visit
(segments visitors by the first ad o Time of most recent visit
they viewed as visitors to the site)
o Total viewing time
 Lifetime page views (segments visitors o Visit count
by the total value of their purchases
over time)
Social influence marketing (SIM) metrics

 SIM score = net sentiment for the brand/net sentiment for the industry
 Net sentiment for the brand = (positive + neutral conversations – negative

conversations)/total conversations for the brand)
 Net sentiment for the industry = (positive + neutral conversations – negative

conversations)/total conversations for the industry)

Internal Use Only
Blogs
 Volume of user participation  Frequency of posts and comments on
 Unique visitors the blog and competitors’ blogs
o Technorati ranking of blogs that
 Country
mention the brand
 Page views
o Technorati ranking of the blog and
 Number of participants/members competitors’
 Volume of user-generated content o Total number of conversations
 Time spent (unique visitors to all sites talking
 Number of brand mentions versus about the brand)
competitors o Total number of times the post has
 Ratio of comments and trackbacks been tweeted or retweeted, saved to
(a method of counting other bloggers Digg, tagged in Delicious and
that reference the post) to posts on discussed on FriendFeed
the blog
Participate in social networks

 Number of friends  Total number of video views
 Number of participants/members o Demographic of viewers
 Unique visitors o Community (includes commentings,
ratings, and favoriting counts)
 Page views
o Email and embed reports
 Volume of user participation
o Link intelligence
 Click-throughs o Aggregation of data
 Page views
 Volume of forwarded content

Internal Use Only
Website communities
 Traffic (number of people visiting the  Unique visitors
community pages)  Volume of user participation
 Interactivity (number of members who  Volume of user-generated content
participate in a specific conversation)  Time spent
 Civility (how civil the conversations are)  Number of customer contracts
 Content (what pieces of the content are  Registration/leads
most/least popular)
 Number of participants/members
Podcasts
 Unique visitors  Volume of user participation
 Number of participants/members  Volume of user participation
 Click-throughs
Ratings/reviews
 Number of participants/members  Time spent
 Volume of user-generated content  Online sentiment (positive/negative)
 Unique visitors  Volume of user participation
 Click-throughs

Internal Use Only
Widgets
 Unique visitors  Growth (average number of increase in
 Number of participants/members users over a specific time period)
 Influence (average number of friends
 Click-throughs among users who have installed the
 Page views application)
 Number of installs  Active users/widgets in the wild
(number of people using the widget on
 Number of active users
a regular basis)
 Audience profiles  Longevity/lifecycle (how long a widget
 Unique user reach or application stays installed by a user
before it is uninstalled)
 Application/widget installs
Advertising in social networks

 Click-throughs  Registrations/leads
 Unique visitors  Page views
 Impact on brand awareness
Twitter
 Volume of user participation  Number of brand mentions
 Online sentiment (positive/negative)  Influence
 Number of members/participants  Number of pass-alongs
 Click-throughs  Number of click-throughs
 Number of customer contracts  Number of visitors coming to
 Impact on brand awareness website from Twitter

Internal Use Only
Facebook
 Number of fans  Active users during the past 7 days
 Total page interactions  Active users during the past 30 days
 Page interactions per post  Canvas page views
 Post quality  Unique canvas pager viewers
 Stream click-through rate (CTR)  Number of application programming
interface calls (API) made
 Discussion posts
 Number of unique users on whose
 Reviews
behalf the application made API calls
 # of user who added the
 Average HTTP request time for canvas
application tab
page
 # of users who added the
 Average Facebook Markup Language
application profile box to their profiles
(FBML) render time for canvas pages
 # of users who added the
application information section
 # of users who bookmarked the
application
 # of users who subscribed to the
application emails

Internal Use Only
Mobile app metrics

Are people finding and using the application?
 Total downloads (count of times app was downloaded)
 App users (number of unique application users over a period of time)
 Active user rate
(ratio of the number of app users to the total number of downloads)
 New users
(count of the number of users that first used the app during a period of time)
How engaged and loyal are the users?
 Frequency of visit
(ratio of the number of visits to the number of users over a period of time)
 Depth of visit
(number of screens viewed on average compared to the number of visits)
 Duration (the average amount of time spent in the application)
 Bounce rate (ratio of the number of user visits that had a single view event to the total
number of visits)

Internal Use Only
From GMR agency
 Total participation per campaign  Geographic location of participants
 Daily/hourly participation  Total click through if using a mobile
 Total promotional entries per keyword website
 Total app downloads
 Total opt-ins/opt-outs to mobile database
 App downloads per day
 Participation by keyword
Mobile analytics
Session reports Event reports
 Sessions  All events
 Session length  App launches
 Session frequency  Sections
 Page views
Users & usage reports
o Campaign parameters
 Unique users o Video plays – all videos
 Operators o Video plays – on demand video plays
 Countries o Video plays – live video plays
Device details reports Error reports

 Devices  Errors
 Device makes
 Operating systems

Internal Use Only
Email - results
Total emails delivered
Number of emails sent to subscribers minus the number that were undeliverable
Clicks to date
Total number of times subscribers have clicked a link within this campaign
Click rate
Clicks To Date divided by total emails delivered
Forecasted clicks
Estimated number of clicks over a normal 8 week lifespan
Forwarded
Number of times a subscriber forwarded this campaign to someone else
Forward rate
Forwarded divided by total emails delivered
Click rate benchmarks by slot

Current Previous click rate
Actual click rate for the offer featured in Click rate for the last email offer that
this report supported featured brand, promotion or
partner PAST SLOT (1-8)
Future Each bar represents the range of click
Forecasted click rate for the offer featured in
rates for each email 'slot' (only applicable
this report <for Initial Report>
slots are shown)

Internal Use Only
Post-campaign survey findings

Awareness
Percent of respondents that answered they are aware of a featured brand (decoys were
included).
Favorability
Percent of respondents that answered they have a favorable opinion of a featured brand
(decoys were included)
Purchase intent
Percent of respondents that answered they were likely to purchase a featured brand or visit
a featured partner within 7 days (decoys were included)
"Is unique"
Percent of respondents that answered the featured brand or partner is unique (decoys
were included)
"Tell a friend"
Percent of respondents that answered they were likely to tell a friend about the featured
brand or partner (decoys were included)
"Is for me"

Percent of respondents that answered the featured brand or partner resonates with them
(decoys were included)
After one week visits

Percentage of respondents that answered they have visited a featured partner in the past 7
days (decoys were included)

Internal Use Only
After one week visits
Percentage of respondents that answered they have visited a featured partner in the past 7
days (decoys were included)
After one week average visits
Average number of times respondents have said they visited a featured partner in the past
7 days (decoys were included)
After one week purchases

Percentage of respondents that answered they have bought from a featured partner in the
past 7 days (decoys were included)
After one week participation

Percentage of respondents that answered they have participated in a featured promotion or
event in the past 7 days (decoys were included)
Control
Email subscribers who were surveyed but not exposed to the featured partners and brands.
Their results were used as a baseline to measure the lift of attributable to the email offer.
Exposed
Survey respondents that received the featured offer.
LIFT
Percent increase of exposed respondents over control group for the specific metric.
Statistical significance
High degree of confidence that results are not due to chance (at least 90% probability).

Internal Use Only
Other metrics to consider

 How much the brand and its associated websites are bookmarked on sites like
Delicious and Flickr.
 Alexa, Compete, and Quantcast rankings
 Brand mentions in discussion forums and on other community websites
 Number of friends and brand mentions on other social network sites that may have a
larger presence in certain regions

Internal Use Only

Internal Use Only
business requirements document
Objective ......................................................................... 6.1.3

BRD approvals ............................................................... 6.1.5
BRD content ................................................................... 6.1.6
Online template ........................................................................................................... 6.1.6

Internal Use Only
Objective The business requirements document (BRD) focuses on defining the

business needs of the project. The BRD identifies business
objective opportunities AND anticipated issues that can be identified prior to
crucial design and development of the project.
The BRD also includes a forecast, market and competitive analysis as well as
measurements and KPIs (Key Performance Indicators) that pertain to brand goals. (Please
refer to KPI’s and Metrics document for a comprehensive listing of metrics and web, mobile,
social and email campaigns.)
By using a common template for collecting business requirements and ensuring important
brand goals and objectives are documented early in the process, project timelines can be
maintained and scope can be contained, for a successful, timely launch.

Internal Use Only
Process The business requirements document includes a RACI Chart, where the roles of team
members and stakeholders in the production and final signing of the business requirements
process document are identified. RACI stands for Responsible, Accountable, Consulted, and
Informed:
! Authorizes, has the ultimate signing authority for any changes to the document
R Responsible for creating this document
A Accountable for accuracy of this document
S Supports, provides supporting services in the production of this document
C Consulted, provides input
I Informed of any changes
Name Company position ! R A S C I
PepsiCo, BIS Digital

R
Media Specialist
Brand Marketing
A S
Representative
Agency
A S
Representative
Brand Director ! C
It is highly recommended that a Director level or higher be required to sign off on the
business requirements documents. This level of sign-off activity early in the project will help
to eliminate last minute, wholesale changes generally due to an oversight by senior
leadership on the goals and objectives of the project.

Internal Use Only
Approval signatures are captured in the Business Requirements Document to indicate

BRD BRD review and agreement with the content in the document and accountability for the sign off of
completed key deliverables.
approvals
approvals Key deliverables that require signature are under a formal level of change control once they
have been signed.
Signature
Deliverable Date Signature Comments
required

Internal Use Only
Online template
BRD content
BRD content The BRD online template includes these topics:
 Executive summary
 Business measurements and KPIs
 Business requirements
 Performance requirements
 Risk analysis
 Implementation plan
 Timing
 Warranty
 Maintenance
 Stakeholders and executive sign off
The BRD online template is a Microsoft Word document available on

PepsiCo’s Agency Portal under the Forms, Tools & Reference section.

Internal Use Only
contract management document
contents
PLACEHOLDER –
AWAITING DOCUMENT FROM LEGAL

Internal Use Only
testing strategy
Objective ......................................................................... 6.3.3

Planning phase ............................................................... 6.3.5
Planning discussion .................................................................................................... 6.3.5
Test plan walkthrough ................................................................................................. 6.3.7
Design phase .................................................................. 6.3.8

Purpose of the test design phase ................................................................................ 6.3.8
Test script and scenario design................................................................................... 6.3.8
Test environment implementation ............................................................................... 6.3.8
Defect management .................................................................................................... 6.3.9
Execution phase ........................................................... 6.3.14

Purpose of the test execution phase ......................................................................... 6.3.14
Iterative execution process ....................................................................................... 6.3.14
Execution activities.................................................................................................... 6.3.16
Recommended test focus areas................................................................................ 6.3.17

Internal Use Only
testing strategy
This document provides testing strategy guidance for digital marketing projects. Testing
Objective strategy objectives include:
objective  Documentation of well-defined testing objectives
 Commitment to create an effective test plan
 Creation of appropriate test cases
 Maintaining an understanding of required use of test data
 Maintaining regular communication and reviews
 Manage the timeliness of defect and issue resolution through a systematic defect
management process
 Test results reported to PepsiCo are meaningful and assist PepsiCo and our
Business + Information Solutions (BIS) teams in making necessary on-going
management decisions. In addition, results which are captured are fed into a
continuous improvement process for digital projects across the organization.

Internal Use Only
testing strategy
A three-phase methodology for all testing is based on the mitigation of risk.

Process Planning: The purpose of the planning phase is to develop a detailed test plan that
process 
will govern the activities during the design and execution phases of the testing.
 Design: During this phase, the system under test is configured, the test execution
environment is installed, and test scripts and any test automation is completed in
preparation for test execution.
 Execution: During the execution phase, the tests are executed, defects are tracked
to resolution, and metrics are collected and reported to the BIS digital specialist.
The BIS digital specialist is to use this guideline and methodology when reviewing testing
strategy and testing plans with the agency.

Internal Use Only
testing strategy
Planning Planning discussion

planning
phase  Discuss the overall functionality of the system/application and the user groups that
phase utilize the target system/application.
 Discuss agency‟s current testing processes.
 Discuss architecture and overview.
 Discuss 3rd party integration and how this will expand the test plan.
 Discuss how we can gather information regarding the requirements, both functional
and non-functional which will be the basis of test cases/test scripts.
 Discuss test data requirements.
 Determine what metrics and measurements will be collected/reported.
 Discuss how issues and defects will be tracked and managed to assure timely
resolution.
 Identify roles and responsibilities.
 Identify key overall milestone dates in the current plan such as when the asset is
scheduled to complete development, and when the asset is scheduled for release.

Internal Use Only
testing strategy
The test plan should include answers to the following concerns.
WHAT: The objectives that are expected of the application, and the objectives of testing.
HOW: The detailed strategy or approach that will be taken to validate the objectives. This
should include documentation of test design criteria, agreement of entry/exit criteria, plans
for defect and issues management, expected deliverables to be created, and plans for
ongoing monitoring and results reporting.
WHEN: The planned milestone dates for test planning, design, implementation, and
execution of the testing.
WHO: Description of all the roles necessary (testers, DBA's, environment setup
people, etc.) and who will need to contribute to the testing.
WHERE: Description of the environments to be used for this testing, handling of

configuration changes during test, plan for creation of test data, data restore needs, etc.
WHAT IF: Description of the anticipated risks (i.e. what could go wrong) and how the project
team intends to address and manage them.

Internal Use Only
testing strategy
Test plan walkthrough

A test plan helps ensure that all stakeholders have a thorough understanding of what the
project team intends to do, and how they intend to do it. This understanding is very
important to ensure that there are no differing expectations of the process which might
surface and potentially disrupt the progress of testing.
Once the test plan has been drafted, a walkthrough with all relevant stakeholders will be
held to present the contents of the plan, and gather feedback. This is very important,
as stakeholders will typically provide very valuable insight which can then be
incorporated back into the plan, making it more robust and effective. In addition,
walking through the test plan with stakeholders can avoid stakeholder disruption of
testing progress.
After the walkthrough, a new draft of the test plan will be created, incorporating all of the
changes resulting from the walkthrough discussions. This will be the baseline test plan
which should be utilized as the starting point for the design phase of the project.
 Walkthrough asset (website, mobile application, social website)
 Review agency‟s testing process
 Identify test cases
 Identify workload mix
 Identify objectives
 Prioritize tests
 Review test environment
 Review test team
 Agree on successful test criteria and testing deadline
 Completion criteria: Test plan created by agency and walkthrough completed

Internal Use Only
testing strategy
Design phase Purpose of the test design phase

The purpose of the test design phase of the methodology is to create thorough test cases
design phase and build out a test environment to test your application. During this phase, test data can be
implemented, as well as any required test automation, test execution monitoring tools, etc.
Ensuring that test design activities are regularly managed against the project plan and that
readiness is achieved is the goal of the test execution phase.
Test script and scenario design

 Meet with the architects, development, and business SME‟s as necessary to
determine exactly what steps will need to be included in test cases and what will
need to be measured in order to test successfully.
 Document all requirements within written test scenarios.
 Create and automate test cases, as necessary.
Test environment implementation

 Implementation of test environment – Ensure that the environment is built to meet the
expectations brought about by the planning phase. Make sure that any variations are
documented and any risks associated with changes are either corrected or signed off.
 Develop necessary test harnesses or peripheral devices that will be necessary for
testing based upon test case requirements.
 Setup necessary test data and baseline data – Ensure that any specific data required
for successful test execution has been established and any data backup/restore
procedures are ready. For some types of testing (such as performance testing), this
might include ensuring that tables are pre-filled with production like volumes of data
to ensure that SQL calls are being tested under realistic conditions.
 Set up of any automated testing and/or system monitoring tools, if applicable

Internal Use Only
testing strategy
Defect management
Defect management is one of the key indicators used to measure both test progress and
quality. A well-managed defect tracking process contributes to the overall success of a
software project. System wide trends with environment or software development project
issues are addressed and solved with the proper metrics and defect resolution procedures.
The purpose of defect management is to:

 Implement the processes to manage the tracking and fixing of defects found during
System, End to End, Regression and user acceptance testing
 Perform root cause analysis
This section describes the process for defect management. It includes details on the
processes to be followed when opening, analyzing, fixing, and retesting defects found
during the web or mobile project. This can include defects found in documentation,
processes, requirements, environments, etc., as well as software problems
Defects
Defect management is the process used to document, track, and close defects in the
system being tested. A defect is a variance from expectations, such as:
 A bug in the code
 An incorrectly stated requirement
 An overlooked requirement
 An incorrect function
 A well-implemented function that is not wanted
 A performance problem
Defects can be found at any point during a project. Each defect found on the project must
be logged to allow tracking and measurement.

Internal Use Only
testing strategy
After being opened, a defect will be analyzed and a cause attributed. Assigning a cause
allows analysis to take place for reporting and management purposes such as determining
quality levels of delivered site/application.
Lastly, a defect needs to be resolved and resolution can result in:

 No action
 A procedural or a program fix
 A change outside project scope
 Cancellation
Defect management lifecycle

When a defect has been identified, it passes through various stages in its life cycle.
Not all defects will pass through all status and some defects may pass through the same
status several times, as the lifecycle allows for some iteration. The status of the lifecycle is
described in more detail later in this document.
All errors detected during each testing phase of the project will be recorded, logged, and
have cause attributed. These measurable errors will then be used to establish the quality
levels of prior testing phases and will assist us in determining error forecast for the
remaining phases.
An essential factor in the successful completion of testing activities is a well-managed defect

management process. This process involves compiling information on defects found during
testing or system operation, and analyzing that information so that trends and significant
events or problems are recognized. PepsiCo requires that defects and their resolutions be
documented and shared with the BIS team so future projects can benefit from these
defect/resolution logs by avoiding similar problem areas.

Internal Use Only
testing strategy
Severity levels
The mission of establishing testing severity levels is to provide a methodology for
introducing and implementing reasonable expectations for classification and fixing of errors.
By categorizing errors, appropriate attention can be placed on problems that are of higher
criticality. Additionally, root cause analysis and other measurements can be collected and
performed. Classifying severity levels achieves the following goals:
 Improvement of management call to problem resolution
 Problems that are clearly documented and understood by all parties
 Objectives that are measurable, tracked and reported on a regular basis
 Clearly stated and agreed roles and responsibilities
Defect severity/priority levels are used to determine the impact of the defect on the testing
process and priority of fixes. Defects and their associated severity/priority level may also
impact whether the exit criteria have been met for testing.
Severity/priority level 1 and 2 defects are serious defects and require close communication
between testers, the business, and development teams during resolution and re-testing to
minimize the impact on the test schedule as well as the timelines in general.
The severity/priority levels code is used to classify the impact of the defect on the
application and the testing process:

Internal Use Only
testing strategy
PepsiCo severity levels table
Level Description
A very severe defect. The system, component, or function will not work, there is no
Priority 1 workaround, and testing cannot continue. This is considered a terminal defect.
Example: A program will not load or the system is not responding.
A severe defect. The entire application component or function will not work, but there
Priority 2 is a workaround and testing can continue. This is considered a serious defect.
Example: A screen does not display properly, but the functions can be used.
A defect. The function tested will not perform as expected and testing can continue.
Priority 3 Example: The screen requires an extra keystroke („enter‟) to process the function.
A minor defect. Testing is not impacted.
Priority 4 Example: The documentation does not match the system. Screen colors are not correct or
there are incorrectly spelled words on the screen.
Sample severity/priority level turnaround times

Each severity/priority level will have a pre-determined „turnaround‟ time in which the support team
responsible for fixing the defect is expected to provide the fix. Turnaround times must be agreed
between PepsiCo/BIS and agency/development firm prior to the beginning of test execution.
Defect turnaround approach is based on defect severity/priority level.

Level Turnaround time (normal working hours)
 Response time = 15 minutes
Priority 1  Resolution target = 2 hours
 Response time = 30 minutes
Priority 2  Resolution target = 4 hours
 Response time = 8 hours
Priority 3  Resolution target = 2 days
 Response time = 2 days
Priority 4  Resolution target = 7 days

Internal Use Only
testing strategy
If testing uncovers many defects, the team responsible for the fixes may not be able to
complete the fixes within the expected turnaround times. Please have agency alert the BIS
specialists if defect quantities will prevent adherence to turnaround schedule.
Set up test environment

 Set up workstations ( if applicable)
 Set up network (if applicable)
 Install testing software and tools ( if applicable)
 Provide test database
 Install test database
 Provide test data
 Install test data
 Completion criteria: Environment set
Develop test cases

 Set up target test platforms
 Design test cases
 Capture test scripts
 Ensure test case traceability
 Ensure updates to test schedule
 Validate test scripts
 Plan test results gathering and reporting process
 Completion criteria: Test cases

Internal Use Only
testing strategy
Execution Purpose of the test execution phase

execution
phase To determine and report to the client if the application or system being tested will function
and/or perform as expected based upon the specific objectives documented in the test plan.
phase
Iterative execution process
Execute the test execution checklist to determine if conditions are prepared for the
execution of a testing.
Execute testing to create the desired functionality or workload volumes as indicated in the
designed test scenario(s).
Create/maintain defects – Make sure that any defects found are entered into the
appropriate defect tracking tool to ensure that they will be reviewed and corrected.
Create/maintain issues – Make sure that any project issues found, which might impact the
success of testing, are reported to the client assigned project manager to ensure that they
will be reviewed and resolved.
Complete analysis of each test and report results and observations – The IBM team should
analyze and interpret the data captured during testing and document any information of
value to help move forward.
Tune configuration and re-retest to determine impact as necessary.

Internal Use Only
testing strategy
Metrics reporting
 Provide information on whether testing is going as planned.
 Identify inhibitors to test project success for corrective action.
 Give ongoing product quality information.
 Indicate test and development workload.
 Determine if test yields meet expectations.
 Manage tests more effectively.
 Predict when testing will be completed.
 Drive overall project success.
Deliverables and sign off – deliver an executive summary

 Document all results and observations, including if and how the project met the
success criteria of testing. The document should include all defects that have been
found and fixed during the test execution phase, as well as any known defects that
remain unresolved.
 Also it is important to ensure that any tuning that has been done is documented,
which might be required for the production environment prior to deployment.
 Sign off: Review the final results and establish a consensus that testing has met the
success criteria and can be considered completed.

Internal Use Only
testing strategy
Execution activities
Execute testing
 Conduct readiness review
 Run test cases
 Evaluate results
 Report defects
 Review defect fixes
 Provide feedback to application developers
 Re-run test scripts
 Completion criteria: End of timeframe reached
Prepare summary
 Develop recommendations
 Summarize test results
 Prepare report
 Completion criteria: Summary delivered

Internal Use Only
testing strategy
Recommended test focus areas

 Unit testing
 System testing
 Functional testing
 User acceptance testing
 Subset: Usability testing
 Performance and load testing
 Operational readiness testing
 Security scanning
Unit testing
Unit testing is the first level of testing after the code has been written and the first
opportunity for dynamic testing. It verifies the code, the internal logic, design, and the paths
within the module being tested for all new or changed code in a program. All error
conditions and exception conditions are generally tested at this time.
These are the objectives of unit level testing:

 Ensure every logical path through a “unit”, as measured against the program
specification from which it was developed, is tested.
 Identify and correct, logical coding errors and demonstrate that all logical paths have
been executed.
 Test the linking of related units.
 Execution and verification of all statement, condition, decision and paths in the
individual piece of code against the specifications and design documents for that code.
 Test exception conditions and error handling.
Verify that the implementation at the module level is defect free.

Internal Use Only
testing strategy
System testing
These tests occur at the end of the development cycle for each release. They are designed
to test the code integration, internal interfaces as well as external interfaces through
combination of simulators, stubs, and integration with development servers.
Functional testing
Functional testing assures that the website or application attributes satisfy the user
requirements.
Audit and controls – Verifies the adequacy and effectiveness of controls and
completeness of data processing results. This would include areas, such as voting, polling,
and loyalty rewards that may require data processing, audits, and controls.
Error handling – Verifies the system function for detecting and responding to exception
conditions. Completeness of error handling determines the usability of a system and
ensures that incorrect transactions are properly handled and there is no negative
consequence to the user experience.
Function – Ensures that the user's business functional requirements are met. Verifies that
each business function operates according to the business requirements document and the
detailed functional requirements documented in the design and concepting phase of the
project. Test conditions are generated to evaluate the correctness of the functional
requirements for both web site and mobile applications.
Multi-user – Verifies the ability of the website and/or application to process more than one
user‟s activity at the same time.
Installation – Verifies that applications can be easily installed and run in the target environment
and includes pre-installation verification and back out tests. This is important in 3rd party
applications and is addressed in Web and mobile process as „Review of 3rd Party Integration.

Internal Use Only
testing strategy
Interface/Inter-system – Verifies that the interconnection between applications and system
functions correctly.
Regression – Verifies that, as a result of making changes to one part of the system or
required function that unwanted changes were not introduced to other parts.
Transaction flow – Verifies the proper and complete processing of a transaction from the
time it enters the system to the time of its completion or exit from the system.
User acceptance testing

The fundamental objective of acceptance testing is to verify the overall business
functionality of the system from an end user perspective and to assure that the overall
system is fit for use, by testing including external interfaces and special requirements.
Acceptance testing simulates the business environment and demonstrates that the system
will perform as expected to the sponsor and end users so that they may accept the system.
BIS may assist agency and development firms in acceptance testing activities related to
functional testing. This includes support for execution of the test cases, defect tracking, and
defect resolution. It is anticipated that UAT tests will be a subset of the QAT test cases.
Entry criteria:
 User acceptance test plan completed.
 Test cases have been defined and are available.
 A full operational/stable environment and application execution environment is in place.
 Skilled resources have been trained, available and prepared.
 A subset of the QAT test cases have been executed.
Exit criteria:
 There are no outstanding severity 5, severity 4.
 Any open severity 3 issues / defects must be formally accepted by PepsiCo/BIS as
not being necessary to resolve prior to exit of the QAT testing phase

Internal Use Only
testing strategy
Usability testing
The agency/development firm will perform usability testing on the site/application platform to
ensure that user experience requirements are met and that the system meets user
experience design specifications. This task is often considered a subset of UAT testing.
Formal defect tracking and resolution will be part of the UAT cycle.
Performance testing
Performance testing is designed to test whether the system meets the desired level of
performance in a production environment. Performance considerations may relate to
response time, turn-around time (through-put), CPU usage, memory and so on.
Entry criteria:
 Performance testing environment is available/stable and need to be configured to
replicate production performance.
 Application performance test requirements have been documented and agreed upon.
 Load and performance test cases and test scripts developed.
 All required performance monitors have been installed and configured.
 Resources have been assigned and are available.
Exit criteria:
 All test cases identified and agreed upon by PepsiCo/BIS have been executed.
 The defined workload is executed at the target level.
 All high priority performance defects if any have been addressed and closed.
 Performance objectives are met, or a mutual agreement by both PepsiCo/BIS and
vendor is in place to address the results. Open issues have been
documented/addressed and an action plan is in place.
 Test results documented and delivered.
 Load and performance test is signed off completed by PepsiCo/BIS.

Internal Use Only
testing strategy
Operational readiness testing
Operational readiness testing involves testing the implementation processes and
procedures to ensure a successful ORT environment can be implemented.
Entry criteria:
 A suitable environment is available and operational
 ORT Test cases created (Using the non-functional requirements)
Exit criteria:
 Test results delivered and accepted by PepsiCo/BIS
Security scanning/testing
Based on the score coming from the risk assessment and process tailoring tool, security
scans should be deployed at the end of the testing phase based on low risk (simple scan),
medium risk (house scanning), or high risk (house scanning + static analysis).
Low risk- Scans for low risk sites can be performed by simple SaaS scanning that does not
require the SaaS consultant to review the results. The results can be optionally reviewed by
internal security.
Medium risk – Medium risk sites should require in house scanning that is reviewed by the
BIS security team or SaaS scanning that requires a consultant review.
High risk – High risk sites require in house scanning that is reviewed by the BIS security
team or SaaS scanning that requires a consultant review in addition to a static analysis.

Internal Use Only
testing strategy

Internal Use Only
capacity planner
Objective ......................................................................... 6.4.3

Introduction ..................................................................... 6.4.5
Online template ........................................................................................................... 6.4.5

Internal Use Only
capacity planner
The capacity planner is not meant to replace the methodology or

Objective
objective
mathematical algorithms used for determining the appropriate IT
infrastructure to support most high-volume web sites.
The planner is meant to assist the hosting provider by capturing marketing and trend
information that many times goes unaccounted for and therefore hinders capacity planning
and can place the website and brand at risk. Risks include website outages, slow page
download or failures, and/or the inability for online forms to capture data or registration
information.

Internal Use Only
capacity planner
The Pepsico Business + Information Solutions (BIS) digital interactive specialist will
Process complete the capacity planner and submit to the hosting provider (Savvis or other 3rd party
process providers) as a supplement to hosting planning and configuration. This will require meeting
with the brand and agency teams to discuss the capacity planning steps and review
previous website histories, proposed media calendars, and influencing events.
Note: Some of the information required in this capacity planner can be lifted from the
business requirements document and repurposed.

Internal Use Only
capacity planner
Capacity planning is the process of determining the website capacity and performance
Introduction capabilities required to meet the future business requirements effectively. In the context of
introduction capacity planning, "capacity" is the maximum amount of users that the website or a
particular function on the website is capable of handling in a given period of time.
Capacity planning consists of three (3) steps:
1. Identify work load patterns and trends
2. Measure performance of current site
3. Model infrastructure alternatives
For steps #1 and #2, see the online form.
Step #3 should be addressed by an Infrastructure Architect and hosting provider.
Online template
The Capacity Planner Template is a Microsoft Word document available on

Internal Use Only
capacity planner

Internal Use Only
project closeout checklist
Objective ......................................................................... 6.5.3

Online template ........................................................................................................... 6.5.3

Internal Use Only
The Project closeout checklist is intended to capture requirements, gain all-party agreement
Objective on project closeout issues, and ensure the appropriate oversight is given to launch assets.
objective
The Pepsico Business + Information Solutions (BIS) digital interactive specialist will initiate a
Process project close out meeting within 10 business days of live deployment of a digital marketing
process project. The closeout meeting will include brand team representation and appropriate
agency/developer representation to gain agreement on necessary handovers and identify
any post-launch issues.
Online template
The Project Closeout Checklist online template is a Microsoft Word document available
on the Digital Resource Center under the Forms, Tools & Reference section.

Internal Use Only

Internal Use Only
30-90 day health assessment
Objective ......................................................................... 6.6.3

Online template ........................................................................................................... 6.6.3

Internal Use Only
The 30-90 day health assessment is intended to review and verify that the asset/website is
Objective meeting agreed Key Performance Indicator (KPI) and performance criteria outlined in the
objective business requirements document.
If results indicate that criteria have not been met, the brand representative and the PepsiCo
Business + Information Solutions (BIS) digital interactive specialist can determine a
recommendation and/or request to the agency for course correction. The BIS specialist will
also help the brand team determine whether course correction is part of the SOW
commitment or a new work order will be required.
At the project close meeting, the 30-90 Day health assessment is to be scheduled.
Process The BIS digital interactive specialist will prepare materials for review including the business
process requirements document, relevant KPIs, and performance criteria. The meeting should
include the BIS digital interactive specialist, the agency and the brand representative(s).
Online template
The 30-90 Day Health Assessment online template is a Microsoft Word document
available on the Digital Resource Center under the Forms, Tools & Reference section.

Internal Use Only

Internal Use Only
accessibility
Description ...................................................................... 7.1.3

Visual .......................................................................................................................... 7.1.4
contents Hearing ....................................................................................................................... 7.1.4
Mobility ........................................................................................................................ 7.1.5
Cognitive ..................................................................................................................... 7.1.5
Goals ............................................................................. 7.1.6

Broad Objectives ......................................................................................................... 7.1.6
Exceptions .................................................................................................................. 7.1.6
Checklists ...................................................................... 7.1.7

Best practice ............................................................................................................... 7.1.7
Software accessibility .................................................................................................. 7.1.7
Web accessibility......................................................................................................... 7.1.9
Java™ accessibility ................................................................................................... 7.1.12
Hardware accessibility .............................................................................................. 7.1.13
Hardware self-contained, closed products ................................................................ 7.1.14
Documentation accessibility ...................................................................................... 7.1.15
References .................................................................. 7.1.16

Internal Use Only
accessibility
Description When you design or modify software to allow access for persons with
different abilities, you make the software accessible. New software
description and applications, however, are introducing new problems and
barriers. There are complex graphics and multimedia applications
that assistive technology simply has not solved. One solution to
these new problems is to put accessibility in the hands of the
developer and content author. Developing a software application that
is accessible by persons with different abilities is relatively easy, as
long as the developer and author follow some basic guidelines.
Assistive technology is a piece of equipment or a software product that is used to increase,
maintain, or assist the functional capabilities of individuals with impairment or disabilities. In
short, it can be any device or technique that assists people in removing or reducing barriers
and enhancing their daily activities. Assistive technologies include screen or text magnifiers,
screen readers or software that reads an application aloud, closed captioning, keyboard and
mouse enhancements, voice recognition software, and highlighting software.
Meeting the standards of an accessible application first requires an awareness of the needs
of the users who have different abilities. The four main categories of disability are visual,
hearing, mobility, and cognitive/learning.

Internal Use Only
accessibility
Each person with a disability might encounter one or more barriers that can be eliminated or
minimized by the developer, the user interface or GUI, the assistive technology, or the
underlying operating system software and hardware platform.
Visual
People with visual disabilities are individuals who are blind, have low vision, or have color
blindness. People who are blind need text comparables for the images used on the Web
page, because they and their assistive screen reader technology cannot obtain the
information from the image. A person who has a visual disability will not find the mouse
useful because it requires hand and eye coordination.
Instead, this person must navigate the application using only the keyboard. For example,
the Tab key is used to move the focus to the item that needs to be selected. A screen
reader then announces the item so the user knows where the focus is on the page. The
user then presses the Enter key instead of "clicking" the mouse button. Those who have low
vision need the assistance of a hardware or software magnifier to enlarge the text beyond
simple font enlargement. When information is presented by color alone, a person who is
color blind misses that information.
Hearing
People who are deaf or hard of hearing require visual representations of auditory
information that the application provides. Solutions for these disabilities include closed
captioning, blinking error messages, and transcripts of the spoken audio. The primary
concern is to ensure that audio output information is provided in a redundant comparable
visual form. Other solutions may include providing a consistent design and using simplified
language that may adapt better for those whose first language is sign language.

Internal Use Only
accessibility
Mobility
People with disabilities that impact mobility have limited movement and difficulty with fine
motor controls, such as lifting, walking, and typing. Mobility impaired individuals experience
difficulties in using the computer's input devices and in handling storage media. Lack of fine
motor control for precise mouse clicks can be an inhibitor to a person with a mobility
disability. Solutions for persons with mobility disabilities include switches, latches, and
controls that are easy to manipulate, and media that are easy to insert and remove, as well
as alternate input devices. Touch screen computers can also pose a problem for people
with mobility issues, if said user lacks fine motor control to make screen selections or
artificial limbs which will not interact with screen. Additional solutions include alternate input
capabilities, such as voice input, simple keypads or the ability to enter information at the
user's own pace.
Cognitive
People with cognitive or learning disabilities, such as dyslexia and short-term memory
deficit, need more general solutions, which include providing a consistent design and using
simplified language.
For example, by using a template, a Web developer can reuse the same layout and design
for each page, so a person with a cognitive disability can more easily navigate through a
website. People with cognitive or learning disabilities can also benefit from redundant input,
such as providing both an audio file and a transcript of a video. By simultaneously viewing
the text and hearing it read aloud, they can take advantage of both auditory and visual skills
to comprehend the material better.

Internal Use Only
accessibility
Accessibility with Purpose: PepsiCo’s Information Technology Accessibility Policy provides

Goals direction to all PepsiCo operating organizations including suppliers and vendors to make
goals PepsiCo I/T offerings accessible to people with different abilities.
Broad objectives
 Employer of Choice: by enabling people with different abilities to fully demonstrate
their capabilities through the elimination or reduction of physical and cultural job
barriers across our company and the expansion of recruitment and professional
development opportunities.
 Brand of Choice: by embracing and reflecting people with different abilities as an

essential and valued part of PepsiCo's culture and marketplace penetration --
including visibility within our marketing activities.
 Partner of Choice: by developing comprehensive, substantive "Best-In-Class" policies

and practices for people with different abilities.
As we continue to innovate and build upon our understanding of opportunities, PepsiCo may
choose to add or update these goals to reflect the new technologies or standards that
become commercially viable.
Exceptions
Definitions of exceptions and undue burden do exist for this policy and require written
approval from the authoritative division executive.

Internal Use Only
accessibility
Checklists Best practice

PepsiCo IT accessibility standards will be based upon the best practices of *IBM, a global
checklists leader in accessibility expertise and standards development. The published standards from
IBM are a hybrid of Information and Communication Technology Accessibility Standards in
Section 508 of the U.S. Federal Rehabilitation Act and the World Wide Web Consortium’s
(W3C) Web Content Accessibility Guidelines (*WCAG 2.0).
* See References at the end of this document.
Software accessibility
In addition to the checklist to help create accessible Windows-based software, the IBM
guideline includes resources such as helpful information about software accessibility test
tools and additional references on software accessibility issues.
http://www-03.ibm.com/able/guidelines/software/accesssoftware.html
Yes/No Keyboard access

Provide keyboard equivalents for all actions.
Do not interfere with keyboard accessibility features built into the operating system.
Yes/No Object information
Provide a visual focus indicator that moves among interactive objects as the input focus
changes. This focus indicator must be programmatically exposed to assistive technology.
Provide semantic information about user interface objects. When an image represents a
program element, the information conveyed by the image must also be available in text.
Associate labels with controls, objects, icons and images. If an image is used to identify
programmatic elements, the meaning of the image must be consistent throughout the application.
When electronic forms are used, the form shall allow people using assistive technology to access
the information, field elements and functionality required for completion and submission of the
form, including all directions and cues.

Internal Use Only
accessibility
Yes/No Sounds and multimedia

Provide an option to display a visual cue for all audio alerts.
Provide accessible alternatives to significant audio and video.
Provide an option to adjust the volume.
Yes/No Display
Provide text through standard system function calls or through an API (application programming
interface) which supports interaction with assistive technology.
Use color as an enhancement, not as the only way to convey information or indicate an action.
Support system settings for high contrast for all user interface controls and client area content.
When color customization is supported, provide a variety of color selections capable of producing
a range of contrast levels.
Inherit system settings for font, size, and color for all user interface controls.
Provide an option to display animation in a non-animated presentation mode.
Yes/No Timing
Provide an option to adjust the response times on timed instructions or allow the instructions
to persist.
Do not use flashing or blinking text, objects, or other elements having a flash or blink
frequency greater than 2 Hz and lower than 55 Hz.

Internal Use Only
accessibility
Web accessibility
In addition to the checklist below, this IBM guideline provides the implementation and
testing techniques and information on tools to help create accessible websites and
Web applications.
http://www-03.ibm.com/able/guidelines/web/accessweb.html
Yes/No Section title

Text alternatives: Provide text alternatives for all non-text content so that it can be changed into other forms
people need, such as large print, Braille, speech, symbols or simpler language.
Text alternatives. All non-text content that is presented to the user has a text alternative that
serves the equivalent purpose.
Non-text content. A descriptive label is provided for time-based media, including live audio-only
and live video-only content. Non-text content that is used to confirm that content is being accessed
by a person rather than a computer is available in different forms to accommodate multiple
disabilities.
Image maps. Client-side image maps are used and alternative text is provided for image map hot
spots. Equivalent text links are provided if a server-side image map is used.
Time-based media: Provide alternatives for time-based media.
Captions. Captions are provided for prerecorded audio content in synchronized media, except
when the media is a media alternative for text and is clearly labeled as such.
Audio and video (pre-recorded). An alternative for time-based media or audio description of the
pre-recorded video content is provided for synchronized media, except when the media is a media
alternative for text and is clearly labeled as such.
Live multimedia. Captions are provided for live multimedia.

Internal Use Only
accessibility
Adaptable: Create content that can be presented in different ways without losing information or structure.
Information and relationships. Information, structure, and relationships conveyed through
presentation can be programmatically determined or are available in text.
Meaningful sequence. When the sequence in which content is presented affects its meaning, a
correct reading sequence can be programmatically determined.
Forms. Form element labels can be programmatically determined.
Tables. Table cells and relationships between cells can be programmatically determined.
Cascading style sheets. Web pages are readable without requiring style sheets.
Sensory characteristics. Instructions provided for understanding and operating content do not
rely solely on sensory characteristics of components such as shape, size, visual location,
orientation, or sound.
Distinguishable: Make it easier for users to see and hear content including separating foreground
from background.
Use of color. Color is not used as the only visual means of conveying information, indicating an
action, prompting a response, or distinguishing a visual element.
Audio control. If any audio on a Web page plays automatically for more than 3 seconds, either a
mechanism is available to pause or stop the audio, or a mechanism is available to control audio
volume independently from the overall system volume level.
Keyboard Accessible: Make all functionality available from a keyboard.
Keyboard. All functionality of the content is operable through a keyboard interface without
requiring specific timings for individual keystrokes, except where the underlying function requires
input that depends on the path of the user's movement and not just the endpoints.
Scripts. Scripts are keyboard accessible. If the content affected by scripting is not accessible, an
alternative is provided.
Applets, plug-ins, and non-HTML content. A link is provided to a directly accessible applet,
plug-in or other application. Alternate content is provided for those applets, plug-ins or other
applications that are not directly accessible.
No keyboard trap. If keyboard focus can be moved to a component of the page using a keyboard
interface, then focus can be moved away from that component using only a keyboard interface,
and, if it requires more than unmodified arrow or tab keys, the user is advised of the method for
moving focus away.

Internal Use Only
accessibility
Enough Time. Provide users enough time to read and use content.
Adjust time response. The user is allowed to turn off, adjust or extend all time limits that are not
a real-time, essential, or 20 hour exception.
Pause, stop, hide. The user is allowed to pause, stop, or hide moving, blinking, scrolling, or
auto-updating information unless it is an essential part of an activity.
Seizures: Do not design content in a way that is known to cause seizures.
Flashing content or below threshold. Web pages do not contain anything that flashes more
than two times in any one second period, or the flash is below the general flash and red flash
thresholds.
Navigable: Provide ways to help users navigate, find content, and determine where they are.
Navigational features. A mechanism is available to bypass blocks of content that are repeated
on multiple Web pages.
Frames. A title and an accessible frame source are provided for each frame.
Page titles. Web pages have titles that describe topic, or purpose.
Focus order. If a Web page can be navigated sequentially and the navigation sequences affect
meaning or operation, focusable components receive focus in an order that preserves meaning
and operability.
Link purpose. The purpose of each link can be determined from the link text alone or from the
link text together with its programmatically determined link context, except where the purpose of
the link would be ambiguous to users in general.
Readable: Make text content readable and understandable.
Language of page. The default human language of each Web page can be programmatically
determined.
Predictable. Make Web pages appear and operate in predictable ways.
On focus. When any component receives focus, it does not initiate a change of context.
On input. Changing the setting of any user interface component does not automatically cause a
change of context unless the user has been advised of the behavior before using the component.
Input Assistance: Help users avoid and correct mistakes.
Error identification. If an input error is automatically detected, the item that is in error is
identified and the error is described to the user in text.
Labels or instructions. Labels or instructions are provided when content requires user input.

Internal Use Only
accessibility
Input Assistance: Help users avoid and correct mistakes.

Error identification. If an input error is automatically detected, the item that is in error is
identified and the error is described to the user in text.
Labels or instructions. Labels or instructions are provided when content requires user input.
Compatible: Maximize compatibility with current and future user agents, including assistive technologies.
Parsing. In content implemented using markup languages, elements have complete start and
end tags, elements are nested according to their specifications, elements do not contain
duplicate attributes, and any IDs are unique, except where the specifications allow these
features.
Name, role, value. For all user interface components (including but not limited to: form elements,
links and components generated by scripts), the name and role can be programmatically
determined; states, properties, and values that can be set by the user can be programmatically
set; and notification of changes to these items is available to user agents, including assistive
technologies.
Ensure that content is accessible or provide an accessible alternative.
Text-only page. If accessibility cannot be accomplished in any other way, a text-only page with
equivalent information or functionality is provided.
Accessibility-supported technologies only. Use accessibility supported technologies.
Any information or functionality that is implemented in technologies that are not accessibility
supported must also be available via technologies that are accessibility supported.
Java™ accessibility
Refer to the IBM guideline for a checklist to help create accessible Java™ 2 applications.
Also at the IBM link is the industry's only set of 100% Pure Java application development
guidelines for accessibility.
http://www-03.ibm.com/able/guidelines/java/accessjava.html

Internal Use Only
accessibility
Hardware accessibility
This checklist can help identify if personal computers and server hardware are compliant.
http://www-03.ibm.com/able/guidelines/hardware/accesshardware.html
Yes/No Controls and latches

Controls and latches should be reachable and operable with one hand and minimal dexterity.
Provide alternative forms of user identification for biometric identification.
Provide an alternative input method for touchscreens or touch-operated controls.
Yes/No Keys, keyboards and keypads
Provide the status of all locking or toggle keys visually and either through touch or sound.
Provide keys which are tactilely discernible without activating them.
If key repeat is supported, the delay before repeat shall be adjustable to at least 2 seconds. Key
repeat rate shall be adjustable to 2 seconds per character.
Yes/No Alternate external connections
Provide industry standard ports for alternative input and output devices.
Yes/No Color and contrast
Use color as an enhancement, not as the only way to convey information or distinguish keys,
controls and labels.
Yes/No Sounds
Provide an interface so that use of system sounds can be known to software.
Provide a physical volume control or provide an interface so that volume can be controlled with
software.
Yes/No Test
Test for accessibility using the techniques in each checkpoint.

Internal Use Only
accessibility
Hardware self-contained, closed products

This checklist can help identify accessible copiers, printers, fax machines, ATMs and kiosks.
http://www-03.ibm.com/able/guidelines/peripherals/accessperipherals.html
Yes/No Controls and latches

Controls and latches should be reachable and operable with one hand and minimal dexterity.
Provide alternative forms of user identification for biometric identification.
Provide alternative input methods for touchscreens or touch-operated controls.
Products shall be usable by people with disabilities without requiring an end-user to attach
assistive technology to the product.
Yes/No Keys and keypads commands
Provide the status of all locking or toggle keys visually and either through touch or sound.
Provide keys which are tactilely discernible without activating them.
If key repeat is supported, the delay before repeat shall be adjustable to at least 2 seconds. Key
repeat rate shall be adjustable to 2 seconds per character.
Yes/No Color and contrast comments
Use color as an enhancement, not as the only way to convey information or distinguish keys,
controls, and labels.
If the user can adjust color and contrast settings, provide a range of color selections capable of
producing a variety of contrast levels. Provide a range of color selections if you allow the users to
adjust the color and contrast settings.
Yes/No Audio
For devices with voice output, provide the ability to adjust the volume. Provide a function to reset
the volume to the default level after every use.
If audio output is provided, provide an industry standard audio connector to allow for private
listening. Provide the ability to interrupt, pause, and restart the audio.
Yes/No Timing
Provide an alert before timed responses expire and allow the user to indicate more time is needed.
Avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz.

Internal Use Only
accessibility
Documentation accessibility
This checklist can help you create accessible informational documentation in
various formats.
http://www-03.ibm.com/able/guidelines/documentation/accessdoc.html
Yes/No Provide documentation in an accessible format

Non-text content: All non-text content that is presented to the user has a text alternative that
serves the equivalent purpose.
Information and relationships: Define information, structure, and relationships.
Color & contrast: Any information that is conveyed by color is also evident without color.
Meaningful sequence: Define document reading order.
Forms: Define form element labels.
Tables: Identify table cells and relationships between cells.
Threshold violations: Do not include text or images that flash more than 2 times in a one second
period.
Navigation: Provide an accessible method to navigate long documents.
Language of page: Define the default language.
Yes/No Document all accessibility features
Provide documentation on all accessibility features including keyboard access.

Internal Use Only
accessibility
References IBM Accessibility Standards – http://www-03.ibm.com/able/guidelines/index.html
Section 508 of the U.S. Rehabilitation Act – http://www.section508.gov/

references
Worldwide Web Consortium (W3C) Web Accessibility Guidelines – http://www.w3.org/WAI/
Americans with Disabilities Act of 1990 (ADA) – http://www.usdoj.gov/crt/ada/adahom1.htm

Internal Use Only
<TITLE PLACEHOLDER>
PepsiCo
Can Spam
STANDARD

CAN SPAM
Description ...................................................................... 7.2.3

contents Guidelines ....................................................................... 7.2.4
Work product: CAN SPAM checklist ........................................................................... 7.2.6
References ..................................................................... 7.2.7

Internal Use Only
CAN SPAM
Description CAN SPAM refers to the law that sets the rules for commercial email,
establishes requirements for commercial messages, gives recipients
description the right to have you stop emailing them, and spells out tough
penalties for violations.
Enforcing stricter data privacy standards helps to ensure compliance to the current and
future laws pertaining to email, maintain a favorable customer relationship, and overall
protect the PepsiCo brand.
This standard should be applied to “any electronic mail message the primary purpose of
which is the commercial advertisement or promotion of a commercial product or service,”
including email that promotes content on commercial websites as stated in the current law.

Internal Use Only
CAN SPAM
Guidelines 1. Don’t use false or misleading header information. Your, “From,” “To,” “Reply-To,”
and routing information – including the originating domain name and email address –
guidelines must be accurate and identify the person or business who initiated the message.
2. Don’t use deceptive subject lines. The subject line must accurately reflect the content
of the message.
3. Identify the message as an ad. The law gives you a lot of leeway in how to do this, but
you must disclose clearly and conspicuously that your message is an advertisement.
4. Tell recipients where you’re located. Your message must include your valid physical
postal address. This can be your current street address, a post office box you’ve
registered with the U.S. Postal Service, or a private mailbox you’ve registered with a
commercial mail receiving agency established under Postal Service regulations.
5. Tell recipients how to opt out of receiving future email from you. Your message
must include a clear and conspicuous explanation of how the recipient can opt out of
getting email from you in the future. Craft the notice in a way that’s easy for an ordinary
person to recognize, read, and understand. Creative use of type size, color, and location
can improve clarity. Give a return email address or another easy Internet-based way to
allow people to communicate their choice to you. You may create a menu to allow a
recipient to opt out of certain types of messages, but you must include the option to stop
all commercial messages from you. Make sure your spam filter doesn’t block these opt-
out requests.

Internal Use Only
CAN SPAM
6. Honor opt-out requests promptly. Any opt-out mechanism you offer must be able to
process opt-out requests for at least 30 days after you send your message. You must
honor a recipient’s opt-out request within 10 business days. You can’t charge a fee,
require the recipient to give you any personally identifying information beyond an email
address, or make the recipient take any step other than sending a reply email or visiting
a single page on an Internet website as a condition for honoring an opt-out request.
Once people have told you they don’t want to receive more messages from you, you
can’t sell or transfer their email addresses, even in the form of a mailing list. The only
exception is that you may transfer the addresses to a company you’ve hired to help you
comply with the CAN-SPAM Act.
7. Monitor what others are doing on your behalf. The law makes clear that even if you
hire another company to handle your email marketing, you can’t contract away your legal
responsibility to comply with the law. Both the company whose product is promoted in
the message and the company that actually sends the message may be held legally
responsible.

Internal Use Only
CAN SPAM
Work product: CAN SPAM checklist

Yes/No
Valid FROM email address?
SUBJECT line not misleading?
Email address is working and available for at least 30 days?
Size of email box is sufficient to hold bounced/returned messages?
Physical postal address included in message?
Domain name registration information accurate?
Opt-out/remove system working properly?
Your mail server is not an open relay or gives non-authorized users access?
You have permission to send via the appropriate mail server?
List was gathered appropriately?
Spell check message?
Common Sense Test: Does the message make sense to a potential recipient?
Message is relevant to target audience? Somehow adds value to their lives?
Personalization is used properly?
Test messages to make sure they render properly in different email platforms?
Privacy Policy posted on Website and link included in email?
Abuse@ & privacy@ email addresses working?
Are messages flagged by anti-spam filters?
Names are not all pasted into TO: line?

Internal Use Only
CAN SPAM
References CAN SPAM Standards –

http://business.ftc.gov/documents/bus61-can-spam-act-compliance-guide-business
references

Internal Use Only
CAN SPAM

Internal Use Only
COPPA
Description ...................................................................... 7.3.3

contents Value ........................................................................................................................... 7.3.3
Area of use .................................................................................................................. 7.3.4
Detail .............................................................................. 7.3.5

Personal information ................................................................................................... 7.3.5
Privacy notice. ............................................................................................................. 7.3.5
Direct notice to parents ............................................................................................... 7.3.7
Checklist ....................................................................... 7.3.14

Location .................................................................................................................... 7.3.14
Content ..................................................................................................................... 7.3.15
Style .......................................................................................................................... 7.3.18
References ................................................................... 7.3.19

Internal Use Only
COPPA
Description The Children's Online Privacy Protection Act, effective April 21,
2000, applies to the online collection of personal information from
description children under 13. The rules spell out what a website operator must
include in a privacy policy, when and how to seek verifiable consent
from a parent, and what responsibilities an operator has to protect
children's privacy and safety online.
The standard is maintained by the FTC. This guide was prepared to help you comply with
the new requirements for protecting children’s privacy online and understand the FTC’s
enforcement authority.
Value
 Ensure compliance to the current and future laws
 Maintain a favorable customer relationship
 Protect the brand

Internal Use Only
COPPA
Area of use
This standard should be applied to websites that are collecting information from children
under the age of 13.These websites are required to comply with Federal Trade Commission
(FTC) Children's Online Privacy Protection Act (COPPA).
If you operate a commercial website or an online service directed to children under 13 that
collects personal information from children or if you operate a general audience website and
have actual knowledge that you are collecting personal information from children, you must
comply with the Children's Online Privacy Protection Act.
 To determine whether a website is directed to children, the FTC considers several
factors, including the subject matter; visual or audio content; the age of models on
the site; language; whether advertising on the website is directed to children;
information regarding the age of the actual or intended audience; and whether a site
uses animated characters or other child-oriented features.
 To determine whether an entity is an "operator" with respect to information collected
at a site, the FTC will consider who owns and controls the information; who pays for
the collection and maintenance of the information; what the pre-existing contractual
relationships are in connection with the information; and what role the website plays
in collecting or maintaining the information.

Internal Use Only
COPPA
Detail Personal information

The Children's Online Privacy Protection Act and Rule apply to individually identifiable
detail information about a child that is collected online, such as full name, home address, email
address, telephone number or any other information that would allow someone to identify or
contact the child. The act and rule also cover other types of information – for example,
hobbies, interests and information collected through cookies or other types of tracking
mechanisms – when they are tied to individually identifiable information.
Privacy notice
Placement
An operator must post a link to a notice of its information practices on the home page of its
website or online service and at each area where it collects personal information from
children. An operator of a general audience site with a separate children's area must post a
link to its notice on the home page of the children's area.
The link to the privacy notice must be clear and prominent. Operators may want to use a
larger font size or a different color type on a contrasting background to make it stand out. A
link in small print at the bottom of the page – or a link that is indistinguishable from other
links on your site – is not considered clear and prominent.

Internal Use Only
COPPA
Content
The notice must be clearly written and understandable, and should not include any
unrelated or confusing materials. It must state the following information:
 The name and contact information (address, telephone number and email address)
of all operators collecting or maintaining children's personal information through the
website or online service. If more than one operator is collecting information at the
site, the site may select and provide contact information for only one operator who
will respond to all inquiries from parents about the site's privacy policies. Still, the
names of all the operators must be listed in the notice.
 The kinds of personal information collected from children (for example, name,
address, email address, hobbies, etc.) and how the information is collected – directly
from the child or passively (i.e. through cookies).
 How the operator uses the personal information. For example: is it for marketing back
to the child? notifying contest winners? allowing the child to make the information
publicly available through a chat room, etc.?
 Whether the operator discloses information collected from children to third parties. If
so, the operator also must disclose the kinds of businesses in which the third parties
are engaged; the general purposes for which the information is used; and whether
the third parties have agreed to maintain the confidentiality and security of the
information.
 That the parent has the option to agree to the collection and use of the child's
information without consenting to the disclosure of the information to third parties.
 That the operator may not require a child to disclose more information than is
reasonably necessary to participate in an activity as a condition of participation.
 That the parent can review the child's personal information, ask to have it deleted
and refuse to allow any further collection or use of the child's information. The notice
also must state the procedures for the parent to follow.

Internal Use Only
COPPA
Direct notice to parents

Content
The notice to parents must contain the same information included within the notice on the
website. In addition, an operator must notify a parent:
 That it wishes to collect personal information from the child
 That the parent's consent is required for the collection, use and disclosure of the
information
 How the parent can provide consent.
The notice to parents must be written clearly and understandably, and must not contain any
unrelated or confusing information. An operator may use any one of a number of methods to
notify a parent, including sending an email message to the parent or a notice by postal mail.
Verifiable parental consent

Before collecting, using, or disclosing personal information from a child, an operator must
obtain verifiable parental consent from the child's parent. This means an operator must
make reasonable efforts (taking into consideration available technology) to ensure that
before personal information is collected from a child, a parent of the child receives notice of
the operator's information practices and consents to those practices.
The FTC continues to use a sliding scale approach to parental consent that varies based on
the use of the child’s personal information. Information obtained for internal purposes has
less rigid requirements than situations where the information may be shared with others
outside PepsiCo. In this case, a more reliable consent method is needed.

Internal Use Only
COPPA
Internal uses
Operators may use email to get parental consent for all internal uses of personal
information, such as marketing back to a child based on his or her preferences or
communicating promotional updates about site content. This is true only if they take
additional steps to increase the likelihood that the parent has, in fact, provided the consent.
For example, operators might seek confirmation from a parent in a delayed confirmatory
email, or confirm the parent's consent by letter or phone call.
Public disclosures
When operators want to disclose a child's personal information to third parties or make it
publicly available (for example, through a chat room or message board), the sliding scale
requires them to use a more reliable method of consent, including:
 Getting a signed form from the parent via postal mail or facsimile.
 Accepting and verifying a credit card number in connection with a transaction.
 Taking calls from parents, through a toll-free telephone number staffed by trained
personnel.
 Email accompanied by digital signature.
But in the case of a monitored chat room, if all individually identifiable information is stripped
from postings before it is made public – and the information is deleted from the operator's
records – an operator does not have to get prior parental consent.

Internal Use Only
COPPA
Disclosures to third parties
An operator must give a parent the option to agree to the collection and use of the child's
personal information without agreeing to the disclosure of the information to third parties.
However, when a parent agrees to the collection and use of their child's personal
information, the operator may release that information to others who uses it solely to provide
support for the internal operations of the website or service, including technical support and
order fulfillment.
Exceptions
The regulations include several exceptions that allow operators to collect a child's email
address without getting the parent's consent in advance. These exceptions cover many
popular online activities for kids, including contests, online newsletters, homework help, and
electronic postcards .
Prior parental consent is not required when an operator:

 Collects a child's or parent's email address to provide notice and seek consent.
 Collects an email address to respond to a one-time request from a child and then
deletes it.
 Collects an email address to respond more than once to a specific request, i.e. a
subscription to a newsletter. In this case, the operator must notify the parent that it is
communicating regularly with the child and give the parent the opportunity to stop the
communication before sending or delivering a second communication to a child.
 Collects a child's name or online contact information to protect the safety of a child
who is participating on the site. In this case, the operator must notify the parent and
give him/her the opportunity to prevent further use of the information.
 Collects a child's name or online contact information to protect the security or liability
of the site or to respond to law enforcement, if necessary, and does not use it for any
other purpose.

Internal Use Only
COPPA
New notice for consent
An operator is required to send a new notice and request for consent to parents if there are
material changes in the collection, or to use or disclosure practices to which the parent had
previously agreed. For example:
 The case of the operator who got parental consent for a child to participate in
contests that require the child to submit limited personal information, but who now
wants to offer the child chat rooms.
 The case of the operator who wants to disclose the child's information to third parties
who are in materially different lines of business from those covered by the original
consent, i.e., marketers of diet pills rather than marketers of stuffed animals.
In these cases, the rule requires new notice and consent.
Access verification
At a parent's request, operators must disclose the general kinds of personal information
they collect online from children (for example, name, address, telephone number, email
address, hobbies), as well as the specific information collected from children who visit their
sites. Operators must use reasonable procedures to ensure they are dealing with the child's
parent before they provide access to the child's specific information.
They can use a variety of methods to verify the parent's identity, including:
 Obtaining a signed form from the parent via postal mail or facsimile
 Accepting and verifying a credit card number
 Taking calls from parents on a toll-free telephone number staffed by trained
personnel
 Email accompanied by digital signature
 Email accompanied by a PIN or password obtained through one of the verification
methods above .

Internal Use Only
COPPA
Operators who follow one of these procedures acting in good faith to a request for parental
access are protected from liability under federal and state law for inadvertent disclosures of
a child's information to someone who purports to be a parent.
Revoking & deleting

At any time, a parent may revoke his/her consent, refuse to allow an operator to further use
or collect their child's personal information, and direct the operator to delete the information.
In turn, the operator may terminate any service provided to the child, but only if the
information at issue is reasonably necessary for the child's participation in that activity. For
example, an operator may require children to provide their email addresses to participate in
a chat room so the operator can contact a child if he is misbehaving in the chat room. If,
after giving consent, a parent asks the operator to delete the child's information, the
operator may refuse to allow the child to participate in the chat room in the future. If other
activities on the website do not require the child's email address, the operator must allow
the child access to those activities.
Timing
The Rule covers all personal information collected after April 21, 2000, regardless of any
prior relationship an operator has had with a child. For example, if an operator collects the
name and email address of a child before April 21, 2000, but plans to seek information
about the child's street address after that date, the later collection would trigger the rule's
requirements. In addition, come April 21, 2000, if an operator continues to offer activities
that involve the ongoing collection of information from children – like a chat room – or
begins to offer such activities for the first time, notice and consent are required for all
participating children regardless of whether the children had already registered at the site.

Internal Use Only
COPPA
Safe harbors
Industry groups or others can create self-regulatory programs to govern participants'
compliance with the Children's Online Privacy Protection Act and Rule. These guidelines
must include independent monitoring and disciplinary procedures and must be submitted to
the Commission for approval. The Commission will publish the guidelines and seek public
comment in considering whether to approve the guidelines. An operator's compliance with
Commission-approved self-regulatory guidelines will generally serve as a ―sa fe harbor‖ in
any enforcement action for violations of the Rule.
Enforcement
The Commission may bring enforcement actions and impose civil penalties for violations of
the rule in the same manner as for other rules under the FTC Act. The Commission also
retains authority under Section 5 of the FTC Act to examine information practices for
deception and unfairness, including those in use before the rule's effective date. In
interpreting Section 5 of the FTC Act, the Commission has determined that a representation,
omission or practice is deceptive if it is likely to:
 Mislead consumers; and
 Affect consumers' behavior or decisions about the product or service.
Specifically, it is a deceptive practice under Section 5 to represent that a website is

collecting personal identifying information from a child for one reason (i.e., to earn points to
redeem a premium) when the information will be used for another reason that a parent
would find material – and when the website does not disclose the other reason clearly
or prominently.

Internal Use Only
COPPA
In addition, an act or practice is unfair if the injury it causes, or is likely to cause, is:
 Substantial
 Not outweighed by other benefits
 Not reasonably avoidable.
For example, it is likely to be an unfair practice in violation of Section 5 to collect
personal identifying information from a child, such as email address, home address
or phone number, and disclose that information to a third party without giving
parents adequate notice and an opportunity to control the collection and use of
the information.

Internal Use Only
COPPA
Checklist Location
checklist 1. Is there a link to your privacy policy on the homepage of your website or on the homepage of the
children’s area of your website?
 If YES, go to the next question.
 If NO, place a link to your privacy policy in the appropriate places.
2. Are the links to your privacy policy near each and every place on your website where you collect
personal information from children?
 If NO, review the areas where you collect personal information from children and put links to your
privacy policy near each of these places.
You must deliver what your privacy policy promises.
3. Does the link to your privacy policy stand out so that the website visitor can locate it easily?
 If YES, describe how the link stands out:
_____________________________________________________________________________
Go to the next question.
 If NO, change your link by using contrasting colors, changing the font or type size, or creating a
noticeable icon.
4. Is the link in a different color, a different font, or a larger type size?

 If NO, change it so it is prominent and stands out. See page 5.
5. Is the link to your privacy policy labeled clearly so a visitor can tell what it is?
 If YES, record the label of your link:
______________________________________________________________________________
Go to the next question.
 If NO, change the link to your privacy policy so that a casual visitor can tell what it is.
6. Does your privacy policy include the names of all the website operators who collect or maintain
personal information from children through your site?
 If NO, revise your privacy policy to include the name of each operator.
The person most familiar with your site’s information practices should complete this checklist.

Internal Use Only
COPPA
Content
7. Does your privacy policy provide mailing addresses for all the website operators who collect or
maintain personal information through your site?
 If NO, does the privacy policy provide contact information (mailing address, telephone number
and email address) for one operator who, in turn, will respond to inquiries from parents on behalf
of the other operators?
 If YES, go to question 10.
 If NO, revise your privacy policy to include full contact information for each operator who collects
or maintains personal information from children through your website, or for one operator who
will respond to all inquiries.
8. Does your privacy policy provide the telephone numbers for all website operators who collect or
 If NO, revise your privacy policy to include telephone numbers for all operators.
9. Does your privacy policy provide the email addresses of all website operators who collect or
 If NO, revise your privacy policy so it includes email addresses.
10. Does your privacy policy state each type of personal information (full name, email address, mailing
address, phone number, etc.) that you collect from children?
 If NO, revise your privacy policy so it tells each type of personal information the site collects.
11. Is your statement of the types of personal information collected descriptive? Is it specific enough to
let parents know the kinds of personal information you will be collecting from their children?
 If NO, revise the statement to be more descriptive.

Internal Use Only
COPPA
12. Does your privacy policy tell parents whether personal information is collected actively — that is
from the child — or passively — for example, through the use of cookies?
 If NO, revise the privacy policy to tell parents how your website collects personal information
from children.
13. Does your privacy policy tell parents how your website will use the personal information that it
collects?
 Yes, go to the next question.
 No, revise the privacy policy so it gives parents that information.
14. Does your website share or disclose children’s personal information with third parties?
 If NO, go to question 19.
15. Does your privacy policy state what kinds of businesses the third parties are engaged in?
 If NO, revise the privacy policy.
16. Does your privacy policy tell parents the general purposes the third parties will use their children’s
personal information for?
 If NO, revise the privacy policy.
17. Does your privacy policy state whether the third parties that your site shares personal information
with have agreed to maintain the confidentiality, security and integrity of the information?
 If NO, revise the privacy policy to address whether the third parties have agreed.
18. Does your privacy policy tell parents they can agree to the collection and use of their child’s
personal information by your site without agreeing to you disclosing the information to third parties?
 If YES, go to question 20.
 If NO, revise the privacy policy to tell parents they have the right to consent to your
site’s collection and use of their child’s personal information, while saying no to your disclosure
of the information to third parties. Then go to question 20.

Internal Use Only
COPPA
19. Does your privacy policy clearly state that your website does not disclose personal information to
third parties?
 If NO, revise the language in your privacy policy to explain that the website doesn’t share
children’s personal information with third parties.
20. Does your privacy policy state that your site cannot condition a child’s participation in an activity on the
child’s disclosure of more personal information than is reasonably necessary to participate in the activity?
 If NO, add appropriate language to your privacy policy.
21. Does your privacy policy let parents know that they can review the personal information that your
website has collected from their child?
 If NO, revise the privacy policy to tell parents they have the right to review the information the
site has collected from their child.
22. Does your privacy policy tell parents how they can review their child’s personal information?
 If NO, revise the privacy policy to let parents know how to review their child’s personal
information.
23. A. Does your privacy policy tell parents they can have their child’s personal information deleted
from your site?
 If YES, go to the next question.  If NO, revise the language in the privacy policy.
B. Does your privacy policy tell parents how they can have their children’s personal information
deleted from your site?
 If YES, go to the next question.  If NO, revise the privacy policy.
24. A. Does your privacy policy tell parents that they can stop your website from further collecting or
using the additional personal information from your child?
 If YES, go to the next question.  If NO, revise the privacy policy as appropriate.
B. Does your privacy policy tell parents how they can stop the further collection and use of their
child’s personal information?
 If YES, go to the next question.  If NO, revise the privacy policy.

Internal Use Only
COPPA
Style
25. Is your privacy policy clear and understandable? Easy to read? Consider testing it with potential
readers.
 If NO, rewrite and simplify the privacy policy so the parents of your visitors would be likely to find
it easy to read and understand.
26. Does your privacy policy give a complete description of your information practices? Does it explain
all the personal information you collect? Does it spell out how you will use the information?
 If NO, review the privacy policy and add information to make the description complete.
27. Does your privacy policy include any contradictory, confusing or ambiguous language?
 If YES, review the privacy policy and revise to remove confusing or ambiguous wording.
 If NO, go to the next question.
28. Does your privacy policy contain any material or content that doesn’t relate to your information
practices?
 If YES, edit the policy so it focuses on your information practices
 If NO, go to the next question.
29. Is your privacy policy well-organized and easy to follow?

 If NO, it’s time to reorganize the information in the policy to make it easier to follow. Consider
using a question and answer format.
30. Do your practices reflect the promises you make in your privacy policy?
 If YES, keep up the good work.
 If NO, go back to square one.

Internal Use Only
COPPA
COPPA Checklist –
http://business.ftc.gov/documents/bus51-you-your-privacy-policy-and-coppa-how-comply-
References
references childrens-online-privacy-protection-act.pdf
What is Personal ACM White Paper –

http://portal.acm.org/citation.cfm?id=1244046&dl=ACM&coll=DL&CFID=5107481&CFTOKE
N=28454000
Children’s Online Privacy Protection Act – http://www.coppa.org/
Federal Trade Commission – www.ftc.gov

Internal Use Only
COPPA

Internal Use Only
data privacy
Description ...................................................................... 7.4.3

contents Value ........................................................................................................................... 7.4.3
Area of use .................................................................................................................. 7.4.3
Detail .............................................................................. 7.4.4

Personal identifiable information (PII) ......................................................................... 7.4.4
Sensitive personal information (SPI) ........................................................................... 7.4.4
References ..................................................................... 7.4.6

Internal Use Only
data privacy
Description This standard provides guidance on how to handle customer data. It

defines personal information and sensitive personal information and
description outlines how to store and transport such information.
Value
 Protect sensitive customer data while stored in a database or moving between
systems.
 Insure customer trust.
 Protect the brand.
Area of use
This standard applies to systems and applications that collect and store personal
information.

Internal Use Only
data privacy
Detail Personal identifiable information (PII)

Required – Personal identifiable information (PII) is any information that identifies or can
detail reasonably be used to identify, contact, or locate the individual to whom such information
pertains. Personal identifiable information includes information that relates to individuals in
their personal capacity, such as an individual's home address. It also includes information
that relates to individuals in their professional or business capacity, such as an individual's
business address. Personal information includes publicly available data elements, such as
name, home telephone number, address, and business contact information.
It should be noted that the data privacy requirements of Austria, Switzerland, and Italy
consider information related to legal entities (such as company name) to be PII as well.
Sensitive personal information (SPI)

Required – Some types of personal information are considered "sensitive" due to many
countries' legal considerations and/or the potential risks that such information could be
misused to significantly harm an individual in a financial, employment, or social way.
Vendors should not collect or retain such information unless it is necessary to achieve a
valid business purpose.
"Sensitive personal information" (SPI) must receive a higher level of protection than PI that
is not sensitive.
The following data elements are always considered SPI within PepsiCo and collection or
retention of any below information will require approval by PepsiCo’s Business +
Information Solutions (BIS) function.

Internal Use Only
data privacy
The following fall in the category of PII and SPI:
 Country identification number (e.g. Social  Political opinion

Insurance Number (SIN), Social Security
Number (SSN)) or other governmentally issued  Trade union membership
identification number such as driver's license or  Religious or philosophical beliefs
passport number
 Data concerning physical and mental health
 Bank routing and account numbers when including state of health, illness, disabilities,
paired with name and/or GPID pathological defects or medical treatments
 Credit card numbers  Biometric or genetic data
 Grade level  Social welfare needs or benefits, or other
 Dependent information social welfare assistance received
 Health and medical information, including  Home phone number

health insurance identification numbers,  Commission or alleged commission of any
payment information, and health care treatment offense and any related court proceedings
or diagnosis
 Other characteristics as specified by
 Date of birth when the year is included applicable law
 Date of birth when paired with name  Age when aligned with name and/or GPID
 Racial or ethnic origin
 Sexual orientation
It is the responsibility of the process owner, creator, or person assembling the data to
assess the risks related to potential misuse or disclosure of the data and to classify and
protect that data appropriately.

Internal Use Only
data privacy
What is Personal ACM White Paper
References http://portal.acm.org/citation.cfm?id=1244046&dl=ACM&coll=DL&CFID=5107481&CFTOKE
references N=28454000
Privacy International – a human rights group formed as a watchdog on surveillance and
privacy invasions by governments and corporations.
Privacy Foundation – the Privacy Foundation researches technologies and their privacy
and security implications.
Consumer Freedom and Privacy – conference is venue for public debate on computing,
privacy and freedom.
Understanding Privacy from BBBOnline – provides tips for consumers and privacy
managers.
PrivacyExchange.org – is an online resource for consumer privacy and data protection
including laws, practices, issues, trends and developments worldwide.
TRUSTe – is a nonprofit initiative to certify and monitor web site privacy, email policies and
practices, and resolve consumer privacy problems. IBM is a member.
BBBOnline – provides privacy resources for small businesses and consumers.
Online Privacy Alliance – a corporate group supporting self-regulatory initiatives to
increase individuals' privacy online and in electronic commerce.
Center for Democracy and Technology – their mission is to promote democratic values
and constitutional liberties in the digital age.
Privacilla.org – "Privacy policy from a libertarian pro-technology perspective."

Internal Use Only
<TITLE PLACEHOLDER>
PepsiCo

STANDARD

data retention
Description ...................................................................... 7.5.3

contents Value ........................................................................................................................... 7.5.3
Area of use .................................................................................................................. 7.5.3
Detail .............................................................................. 7.5.4

Legend ........................................................................................................................ 7.5.4
Marketing and advertising data ................................................................................... 7.5.5
Information technology data ........................................................................................ 7.5.5
References ..................................................................... 7.5.6

Internal Use Only
data retention
Description This standard provides guidance on how long to manage customer

data. PepsiCo has adopted a records management policy to achieve
description a consistent, organized, and effective approach to administering
records, from creation, through active use, storage, and disposal.
Value
The records management policy protects sensitive customer data while in the database or
routing between systems. This helps ensure customer trust and protect our brand.
Implementing a data retention policy is necessary to improve and/or maintain the overall
performance of various system functions. Without implementing a data retention policy,
systems are subject to decline in transaction response times, backup/recovery processes,
and overall system administration. In addition, unmonitored space requirements cause an
increase in the cost of both physical hardware and support services.
Area of use
Required – Customer, promotional, and tracking data should leverage a data
retention plan.

Internal Use Only
data retention
Detail This document provides some of the critical data retention schedules for customer facing
applications. For a complete listing, please reference the PepsiCo Record Management
detail Policy and the PepsiCo Records Retention Schedule.
Legend
Code Definition
C Current Year
EXP Expiration or termination date, including the expiration date of a contract,
patent, permit or warranty; the expiration of a confidentiality obligation; the date
on which a lawsuit or dispute is concluded by a final court judgment or
settlement; date the matter is deemed closed; the date of an asset disposition;
the date when a document is superseded; the termination of active employment;
the abandonment of a trademark
P Permanent
TA Denotes records that must be kept for Tax Audit purposes and that, upon the
expiration of the stated retention period, will require approval by the Tax
Department prior to destruction. Questions should be addressed to the Tax
Department.

Internal Use Only
data retention
Marketing and advertising data

Retention
Record Types
Period
Consumer call logs/correspondence (including emails from consumers) C+2
Promotions/sweepstakes related documentation C+3
Records supporting and validating advertising and marketing claims C+5
Sponsorship, agency, talent, media, promotional and fulfillment house
agreements EXP + 6 (TA)
Information technology data

Record Types Retention Period
Minimum of 30
System and application log files
days
System maintenance documents (including disaster recovery
priority applications, avian flu, and business continuity plans for EXP + 2
field applications)

Internal Use Only
data retention
PepsiCo Record Management Policy
PepsiCo Records Retention Schedule

References
references

Internal Use Only
domain name server (DNS)
Description ...................................................................... 7.6.3

contents Value ........................................................................................................................... 7.6.3
Area of use .................................................................................................................. 7.6.3
Detail .............................................................................. 7.6.4

Flowchart – United States ........................................................................................... 7.6.4
Roles ........................................................................................................................... 7.6.4
Partners and tools ....................................................................................................... 7.6.5
Domain name creation and purchase ......................................................................... 7.6.7
Process to ensure only PepsiCo email address is allowed ......................................... 7.6.8
CSC process for user validation .................................................................................. 7.6.8
Existing users and their access rights ......................................................................... 7.6.9
Purchasing process - Europe .................................................................................... 7.6.10
Checklist ....................................................................... 7.6.12

Domain name request ............................................................................................... 7.6.12
ID creation ................................................................................................................. 7.6.12
ID deletion ................................................................................................................. 7.6.13
International detail ........................................................ 7.6.14

Flowchart – proposed................................................................................................ 7.6.14
Roles ......................................................................................................................... 7.6.14

Internal Use Only
Description This standard pertains to the registration of new domain names,

domain name server (DNS) records, and the creation of approved
description user IDs.
Value
Why do we own them?
We need to own our assets. Owning DNS records helps us in multiple ways: brand
protection; internal and external sharing of information; email, promotional, and defensive
reasons; along with other business reasons.
How do we own them?

Our DNS records are kept in a central location because we need to know what we own and
we need to protect and control our assets.
Area of use
This standard applies to registration and management of all PepsiCo domain names.

Internal Use Only
Detail Flowchart – United States

Refer to the flowchart on the following page.
detail
Roles
DNS management administrator - The DNS process is managed by the DNS
management administrator (DNMA). It is the administrator’s job to shepherd the request
through the naming process.
*Important: the DNMA leverages special tools to perform a search for the domain
name. Publicly searching a domain name from a public registry may allow domain
squatters to grab the name.
Internal legal team – Determines if a trademark is required for a specific domain.
Corporation Services Company – In the event a domain name is owned by an external

entity, the business has the ability to engage in a bidding process with the external owner in
order to obtain the domain name.
Brand sponsor – a brand representative initiates the request by defining the domain name
and the business unit who will own the domain name. The brand team also makes decisions
on whether to pursue a domain name that is externally owned.
Digital interactive specialist – Acts as the contact point for the project. The specialist
insures the overall development process is managed and followed.

Internal Use Only

Internal Use Only
Partners and tools

CSC = Corporate Service Company
NC2 = NameConsole 2, CSC’s tool
DNMA = Domain Name Management Administrator
Ownership and trademark issues are a process of legal.
DNS is a process of PepsiCo’s Business + Information Solutions (BIS) function.
PepsiCo name servers must be used.
Any variation from BIS DNS servers requires approval of security and legal.

Internal Use Only
Domain name creation and purchase

All domain name purchase communication must be sent via email or through NC2 for
documentation purposes.
Scenario I
 Domain name requestor contacts BIS DNMA via email with request.
 If request comes from a vendor, internal contact must be included.
 A request should include SAP cost center code, business unit, domain and other key
information.
 Approval from internal contact is obtained by BIS DNMA.
 Legal to be contacted if trademark infringement clearance is necessary.
 Domain name is purchased by BIS DNMA via CSC NC2 or email.
 Requestor/internal contact is notified via email of successful purchase.
Scenario II – Domain is already owned by external entity

 Domain name requestor contacts legal or BIS DNMA.
 A request should include SAP cost center code, business unit, domain and other key
information.
 Legal or BIS DNMA contacts CSC via email to make the purchase.
 Only BIS DNS servers, CSC’s NS2’s default, servers can be declared.

Internal Use Only
Modifications
 Legal has authority to make registration changes.
 BIS has authority on DNS declaration changes.
 All DNS declarations other than BIS must have approval of security and legal except
in the event of the domain name being transferred in. In this case a reasonable
amount of time (usually 10 days) is needed to rebuild DB files on PepsiCo DNS
servers so the DNS can be transferred with no interruption in a live site.
 It is the responsibility of BIS DNMA to list BIS name servers once DNS team has
rebuilt DB files.
If an exception DNS is processed via phone to CSC, it must be accompanied by a

confirming email to ensure source.
Process to ensure only PepsiCo email address is

allowed
CSC will only acknowledge email requests that come from a PepsiCo email address.
CSC will only act on requests that come from an approved user.
CSC process for user validation

CSC maintains ID approved user names in individual business unit accounts.
Access is granted only to those on approval list.
Only DNMA’s are authorized to approve a new user ID, abandon a domain name, or
change DNS.

Internal Use Only
Existing users and their access rights

Anna Raisor – DNMA – full access
Latha Suryanarayan – DNMA – full access
David Castellano – DNMA – full access
Matthew Cruse – DNMA – full access
Sonya Coleman – Frito-Lay Legal – purchasing and registration rights for Frito-Lay
Deborah Ann Luttrell (Paralegal) – FLNA CCTLD (International names) – purchasing and
registration rights for PepsiCo
Joe Feretti (VP of legal) – FLNA CCTLD (International names) – purchasing and
registration rights for PepsiCo
Janet Silverberg - QTG CCTLD (International names) – purchasing and registration rights
for PepsiCo
Kelly Lasponara – Pepsi CCTLD (International names) – purchasing and registration rights
for PepsiCo
Jeanne McCabe - Pepsi CCTLD (International names) – purchasing and registration rights
for PepsiCo
Shanta Castillo – Pepsi GTLD (domestic names) – purchasing and registration rights for
PepsiCo

Internal Use Only
Purchasing process - Europe

 All marketing and legal groups are notified and required to order the registration of
domain names through BIS domain name management (currently SPA – BIS Domain
Management and VERY SOON TO BE SharePoint tool.)
 Domain name is registered by the domain name management administrators (with
our preferred registrar) and a confirmation is sent back to requestor. (2 day SLA)
 DNS: When DNS is ready to be configured, send IP address (and only 1 IP address,
as we don’t do any load balancing on our end) to the Domain Name Management
Group. (3 day SLA). Using PepsiCo Name Servers to configure DNS is mandatory.
 All domain names are on an auto-renew basis. The reason being that is easier and
less expensive to maintain a domain name than to allow it to expire and then attempt
to re-register. Your list of current domain names will be provided any time you ask.
Presently the domain name administrators are Bryan Deluca and Anna Raisor
Billing
Billing needs be established before any domain name orders can be submitted.
Contact a domain name administrator and provide 2 internal names along with address and
phone. Your business unit will be established and you will be billed monthly and directly
from CSC.
Transfers
Existing domain names or domain names registered outside this established process need
to be transferred into your business unit which is part of PepsiCo’s domain name portfolio.
There are many variables and each will be addressed individually. Contact your domain
name administrator for additional/current information.

Internal Use Only
Domain name owned by someone else and you want it
There is an established process to purchase a domain name from a third party.
For $100 you are able to order an evaluation of the domain name to get a clear
understanding of the market value in addition to other pertinent information.
We use a third party for negotiating. Rules and costs vary, depending on country and type
of domain name. All exchanges of funds and domain names occur through an escrow
account so we remain anonymous until the transaction is complete. Further detail is
available upon request.

Internal Use Only
Checklist Domain name request

checklists Yes/No
Domain name requester contacts BIS DNMA via email with request.
If request comes from a vendor, the required internal contact is included.
Approval from internal contact is obtained by BIS DNMA.
Legal is contacted if trademark infringement clearance is necessary.
Upon approval BIS DNM contacts CSC via email to have the ID created with
appropriate access rights.
Domain name is purchased by BIS DNMA via CSC NC2 or email.
Requestor/internal contact is notified via email of successful purchase.
ID creation
Yes/No
Persons requesting ID creation for access to the CSC NS2, contact BIS,
domain name management administrator.
All CSC NS2 access requests must be accompanied by the respective
trademark attorney.
BIS DNMA receives request and reviews for access business requirement
and access restrictions.
BIS DNM determines access rights.
Upon approval BIS DNM will contact CSC via email to have the ID created
with appropriate access rights.

Internal Use Only
ID deletion
Yes/No
Respective legal groups’ trademark attorney initiates the ID deletion process.
Trademark attorney notify BIS DNMA.
BIS DNMA to communicate deletion to CSC.
BIS DNMA contacts CSC for deletion.
BIS DNMA reviews CSC NS2 access every 90 days. Any ID creation not
active for 180 days will be will be disabled by BIS DNMA.

Internal Use Only
International Flowchart – proposed process

international
detail Refer to the flowchart on the following page.
detail Roles
DNS management administrator – The DNS process is managed by the DNS
administrator. It is the administrator’s job to shepherd the request through the naming
process.
*Important: the DNS management administrator leverages special tools to perform a
search for the domain name. Publicly searching a domain name from a public registry
may allow domain squatters to grab the name.
Corporation Services Company – Manages the purchasing of the international domain

name. CSC also sends reports back to the domain management administrator about
currently owned URLs and expiring URLs.
Brand sponsor – a brand representative initiates the request by defining the domain name
and the business unit who will own the domain name and the country for which the domain
is being purchased.
Digital interactive specialist – Acts as the contact point for the project. The specialist
insures the overall development process is managed and followed.
DNS specialist – Pre-configures the domain names within the DNS servers. Pre-
configuration is sometimes required for international domain name purchases.

Internal Use Only

Internal Use Only

Internal Use Only
<TITLE PLACEHOLDER>
PepsiCo
Hosting Security
STANDARD

hosting security
Description ...................................................................... 7.7.3

contents Area of use.................................................................................................................. 7.7.4
Stakeholders ............................................................................................................... 7.7.4
PepsiCo BIS liaisons ................................................................................................... 7.7.5
Detail .............................................................................. 7.7.6
Process overview ........................................................................................................ 7.7.6
Hosting access request form ....................................................................................... 7.7.6
Timing guidelines for effective project planning .......................................................... 7.7.7
Hosting environment platform and services ................................................................ 7.7.9
Services NOT provided or supported ........................................................................ 7.7.12
Common links ........................................................................................................... 7.7.12
Interactive agency/developer responsibilities ............................................................ 7.7.13
Marketing brand team responsibilities ....................................................................... 7.7.15
BIS liaison responsibilities ......................................................................................... 7.7.16
UHE governance council ........................................................................................... 7.7.17
Domain/DNS management ....................................................................................... 7.7.18
Consumer feedback (contact us) .............................................................................. 7.7.19
Dark site crisis communication .................................................................................. 7.7.20
Website statistics (Urchin) ......................................................................................... 7.7.20
Content delivery network ........................................................................................... 7.7.21
Hosting environment access ..................................................................................... 7.7.21
Work product ................................................................ 7.7.25
References ................................................................... 7.7.26

Internal Use Only
hosting security
Description This standard defines the hosting requirements for all PepsiCo
applications and infrastructure projects which require 'production'
description oriented server and/or storage hosting services in any geography
or country.
PepsiCo’s Business + Information Solutions (BIS) group is the information technology (IT)
function at PepsiCo. BIS partners with Savvis to host the consumer-facing websites for the
brands of PepsiCo Corporate, Quaker, Tropicana, Gatorade, Frito-Lay, and limited PepsiCo
international websites. Savvis is responsible for providing a solid, secure, and reliable
Internet hosting environment that is based on standard hardware and software
configurations that enable each brand’s interactive agency to independently develop and
manage its content.

Internal Use Only
hosting security
Area of use
This document should be reviewed by each brand’s interactive manager and then provided
to the interactive agency and their developers prior to any design or development. Please
familiarize yourself with the information in this document as it will ensure a smooth and
efficient deployment of your site to the PepsiCo Universal Hosting Environment (UHE).
Stakeholders
Marketing Brand team – Internal marketing managers assigned to one or more brands and
given the authority to represent and conduct business on behalf of the brand.
PepsiCo Business + Information Solutions (BIS) – Internal team that is dedicated to

PepsiCo’s information technology needs. Acts as a liaison between all parties but is not
responsible for content development.
Interactive Agency – External partner contracted by the marketing brand team to design,
develop, and maintain the content of a consumer-facing website.
Hosting Vendor – External partner Savvis provides all hardware, software, and connectivity
for consumer-facing websites.

Internal Use Only
hosting security
PepsiCo BIS liaisons

The following PepsiCo BIS liaisons work with the hosting vendor, interactive agency, and
brand teams. Contact your liaison directly with requests, copying Savvis as necessary. All
change requests require BIS liaison approval. Please contact/copy your BIS liaison if
emergency contact with Savvis is necessary. Your BIS liaison is your first point of contact.
Quaker/Tropicana/
Frito-Lay PepsiCo Corporate PepsiCo Beverages
Gatorade
Paul Longo Stacey Patterson John Charbonneau John Troll
paul.longo@ stacey.patterson@ john.charbonneau@ john.troll@pepsico.com

pepsico.com pepsico.com pepsi.com
914.801.1742
312.821.2922 972.963.6710 914.249.8822
Additional PepsiCo contacts

Julita Stinebaugh Greg Koehlinger
BIS/UHE Billing BIS/Technical Liaison/UHE Governance

Julita.Stinebaugh@pepsico.com Greg_Koehlinger@pepsico.com
312.821.2604 312.821.2174

Internal Use Only
hosting security
Detail Process overview

 Brand team provides this document and the Hosting Access Request Form to its
detail interactive agency at the beginning of any campaign or relationship.
 Interactive agency reviews this entire document and then completes the Hosting
Access Request Form for new sites, databases or environment changes.
 Interactive agency submits Hosting Access Request Form and any supporting
documents to the BIS liaison at least 20 business days prior to live site launch.
 BIS technical liaison reviews the request, validates alignment with the hosting
environment standards. After review is complete, the BIS technical liaison then
schedules appropriate calls among the brand, interactive agency, hosting vendor,
and BIS to discuss and understand specifics of the request.
 Upon approval by PepsiCo’s UHE Governance Council, the hosting vendor
processes the request, working directly with the interactive agency to set up the site
to specifications and standards.
Hosting access request form

The Hosting Access Request Form is a Microsoft Excel document available on
PepsiCo’s Agency Portal under the Forms, Tools & Reference section, in the Templates
folder. It should be used for requests including new sites, database, environment changes,
and access requests. Retirement requests may require a Retirement Form.

Internal Use Only
hosting security
The completed form(s) should be returned to your division’s BIS liaison listed earlier.
The interactive agency works with the BIS liaison on all initial correspondence for new sites
and major changes to any site. This includes any change to the hosting environment that
requires the hosting vendor’s involvement. Once the relationship has been established, the
interactive agency will be provided a direct hosting vendor contact to discuss requests and
for any technical issues. Please copy your BIS liaison on all communications with the
hosting vendor. The interactive agency does not need to involve the hosting vendor or BIS
with standard content changes.
Timing guidelines for effective project planning

The Hosting Access Request Form should be submitted 20 business days prior to staging or
production environment setup. This allows all teams involved to properly review and
schedule discussions with the involved parties. Depending on the complexity of the
environment, longer lead time may be required if additional hardware or software must be
procured.
Other timing considerations include:
 Domain Name (URL) - New domain registration complete prior to campaign planning
by working with PepsiCo Domain Management.

Internal Use Only
hosting security
 New Hosting - Requirements should be submitted 20 business days prior to projected
launch date, allowing 10 days to review request and set up environment and 10 days
to test in staging prior to moving to production. Agency should ready site in the
agency development environment prior to deployment to PepsiCo/Savvis staging.
 New or Changes to Access – Please allow 2 business days to process a request.
 Testing – The interactive agency must work with BIS and the brand team to complete
testing and validation of the site.
o Unit and System Test – Completed by interactive agency on interactive
agency equipment. Optionally, complete System Test on Savvis Staging
environment.
o Quality Assurance Testing – Completed by BIS liaison with or without
additional testers on Savvis Staging environment.
o User Acceptance Testing – Completed by brand team on Savvis Staging
environment.
o Brand team gives final approval for site go-live. Brand responsible for
obtaining appropriate approvals (i.e., brand management, legal, etc.).

Internal Use Only
hosting security
Hosting environment platform and services

PepsiCo provides the following base services for all sites in the UHE:
 Shared Website and Application Hosting with separate Production and Staging
environments
 Firewall (traditional) and Application Firewall Security
 Secured FTP (sFTP) access to staging and production environments
 Load balancing on high usage sites
 UHE service offerings
o Recipes service (SOAP protocol)
o Product locator service
o Consumer response feedback service
 Disaster recovery and backup
 Urchin 6.6 Web analytics and reporting
 Outbound SMTP email service (i.e., send to a friend). Mass mailings not permitted.
 URL monitoring
 Automated backups
 DR failover

Internal Use Only
hosting security
These additional services are also supported but may incur incremental costs:
 Database: MySQL or Microsoft SQL Server 2005. MYSQL read/write databases

required to use InnoDb table format.
 Coldfusion MX 8 (Windows sites only)
 Content Management System (CMS): Telerik Sitefinity or OpenText red.dot
 Search functionality via Google Site Search
 SSL certificates
 Content Delivery Network (CDN)
 Video transcoding and integration with CDN hosting
 Load testing
 Dark Site crisis communication

Internal Use Only
hosting security
Interactive agencies should indicate a preferred environment on the Hosting Access
Request Form. The BIS liaison will review the request and provide guidance. The UHE
governance council reserves the right to allocate sites based on load and availability
of resources.
Environments Windows Linux

Operating
Windows Server 2003 32-bit Red Hat Enterprise 4.1.2-14
system
Web server IIS 6.0 Apache 2.2.15
Database SQL Server 2005 MySQL 5.0.45-7 Enterprise
ASP.NET 1.1, 2.0, or 3.5 sp1, PHP 5.1.6 or 5.3.1 with Zend
Software
PHP 5.2.9-2 Engine v2.3.0, Perl, Tomcat
Any other software necessary should be communicated as part of the Hosting Access
Request Form. Any incremental cost will be allocated to the site.

Internal Use Only
hosting security
Services NOT provided or supported

The list below identifies (but is not all-inclusive of) services not provided by the UHE:
 OpenSSH/Telnet access
 RDP/Terminal Services (console) access
 CMS platforms other than Telerik Sitefinity and OpenText red.dot
 Mass mailing campaigns or “email blasts” generated within the UHE or using UHE
resources. Sending email blasts should not be done within our UHE servers because
of the risk of becoming blacklisted as a spammer.
 Email hosting
 Flash Media Server hosting (contact BIS liaison for preferred vendors)
Note: PepsiCo does not currently have a PepsiCo-preferred third-party email blasting
vendor. Please work with your BIS liaison to discuss your specific needs.
Common links
For Frito-Lay sites, the following pages are provided on fritolay.com and should be linked
rather than recreated for all brand sites:
 Privacy Policy - http://www.fritolay.com/privacy-policy.html

 Terms and Conditions - http://www.fritolay.com/terms-of-service.html
 Contact Us - http://www.fritolay.com/about-us/contact-us.html

Internal Use Only
hosting security
Interactive agency/developer responsibilities

 In partnership with brand, coordinate and procure all domain names through
PepsiCo. Domain names and promotions are the property of PepsiCo and managed
by PepsiCo DNS.
 Agencies or individuals should never procure a domain name for PepsiCo.
 Provide advanced notice and ensure proper planning for the success of website
promotions.
 Maintain independent development environment. The hosting vendor provides
staging and production environments only.
 Obtain BIS and brand approval on Requirements and Design documents.
 Design and construct to requirements and contract (development/staging, testing,
deployment, content maintenance, break/fit support).
 Embed UTM code and other tracking requirements for statistical reporting.
 Provide agency firewall IP addresses to enable FTP access to hosting environment.
o Developers must utilize agency’s network to connect.
o Firewall access will be granted to office-only location of agency/developer.

Internal Use Only
hosting security
 Maintain and backup development site.
 Create, update, and manage all site content including uploading content to staging
and production environments.
 Test sites in staging and production in partnership with the brand team.
 Estimate traffic projections with the brand team to ensure adequate capacity is
available. To ensure the quality of service to consumers during highly visible
promotions, we recommend conducting a load test at least 10 days before launch.
The results of the test will allow the hosting vendor and/or interactive agency to fine
tune the deployment.
 Ensure the security and confidentiality of websites by limiting knowledge of ID /
password credentials to a small group. If a developer with knowledge of the ID /
password leaves the interactive agency, please notify BIS immediately so the hosting
vendor can change the password.

Internal Use Only
hosting security
Marketing brand team responsibilities

 Procure all domain names through PepsiCo. Domain names and promotions are the
property of PepsiCo and managed by PepsiCo DNS.
 Agencies or individuals should never procure a domain name for PepsiCo.
 Define site requirements.
 Ensure all external partners are aware of the guidelines and process in this
document.
 Select and manage interactive agency relationship. BIS and the hosting vendor will
work with all parties equally.
 Notify BIS of any changes in interactive agency relationships.
 Provide BIS early notice of high-profile or large campaigns that will generate traffic
significantly above normal levels.
 Escalate any issues to BIS.
 Testing and stage gate approvals.
 The brand team is responsible for all reviews and approvals with brand management,
law department, etc.

Internal Use Only
hosting security
BIS liaison responsibilities

 Actively participate in UHE governance council to:
o Work with the hosting vendor and BIS teams to define hosting strategies and
standards.
o Establish and maintain UHE standards and best practices.
o Create and maintain UHE processes and forms for requesting new sites,
databases or environment changes, access requests, and retiring a site.
o Support alignment to PepsiCo project methodology.
 Serve as primary point of contact for Division external Web hosting needs.
 Manage overall relationship between interactive agency and our hosting vendor.
 Manage communications between brands and website development partners for on-
going maintenance and Website redesigns
 Provide tactical assistance to all parties involved with hosting.
 Track division sites and appropriate contacts--brand and agency.
 Obtain financial approvals for AOP and UHE financial changes throughout the year
 Manage division communications regarding UHE, including:
o Training opportunities
o Financials
o Urchin IDs and passwords

Internal Use Only
hosting security
UHE governance council

Council team members
The core UHE governance council consists of a BIS technical lead, all divisional liaisons,
and billing.
Mission statement
The council mission is to maintain and enforce standard support processes, procedures and
best practices; effectively manage the technical footprint; meet the needs of the business;
manage change, and review financials.
The council reviews hosting requests and can:

 Request additional information
 Approve the request
 Approve the request with stipulations and/or recommendations
 Address financial implications of the request
 Deny the request
Future growth opportunities of the council may be defined.

Internal Use Only
hosting security
Domain/DNS management
Domain name management
All domain names used for PepsiCo promotions must be acquired and owned by PepsiCo.
PepsiCo’s DNS servers must be in each domain record. In the event a domain is owned by
an interactive agency or other 3rd party, the PepsiCo Domain management team must be
contacted to execute the ownership transfer process. Request additional information.
 To expedite requests, please contact your division’s BIS liaison or send all requests
and questions to domain_management@pepsico.com.
 Approval from the Brand team is required to process a new domain name request.
 Response times for a domain name request can vary greatly so please do not
proceed with a campaign until the domain name has been confirmed by the Domain
management team.
 Upon request and with brand cost approval, domain name ownership can be blocked
for viral or secret promotions.
 Upon request, domain names can be configured to a generic "coming soon" page.
 Recommendation regarding use of subdomains:
www.sitename.com/promotion,
NOT www.promotion.sitename.com
Neither example above requires purchasing a domain. However, using
www.promotion.sitename.com requires setup of a new website, while using
www.sitename.com/promotion does not. When appropriate, BIS recommends using
the www.sitename.com/promotion format to save setup time and maintenance cost.
Domain name Server updates

For all other hosting-related DNS requests, please contact your BIS liaison. BIS & brand
team approvals are a requirement before any changes can be made.

Internal Use Only
hosting security
Consumer feedback (contact us)

PepsiCo divisional Consumer Affairs teams manage all interaction between the consumer
and the company via phone, postal mail, and email. PepsiCo has an integrated consumer
response database that is used to track the consumer interactions. Before placing any
contact information or forms on the website, the brand team should have a discussion with
Consumer Affairs to setup the interfaces. Options include:
Feedback Form – BIS can provide a common interface that can be re-skinned and placed
on any brand website. The form will submit data directly into the consumer response
database. Allow 15+ business days after contacting BIS consumer response team for a
contact us function to be fully integrated.
Product Locator Integration – This is a Flash web application that returns store location of
PepsiCo products. Users drill down through a product hierarchy then specifying their zip
code to find product availability.
Phone / Postal Mail – The standard consumer affairs contact information can be placed on
the website similar to the back panel of packaging.
BIS does not recommend or support the creation of a stand-alone database or application
on a brand website that stores detail consumer information subject to privacy laws. Any
exception to this guideline must be approved by PepsiCo Legal and submit to BIS review.

Internal Use Only
hosting security
Dark site crisis communication

PepsiCo has a common dark site communication tool for communicating with the public
during a crisis. The Dark Site is a requirement for QTG brands and corporate websites.
This basic functionality should be implemented to enable Consumer Affairs to quickly post
messages on any websites without any agency intervention needed. The website home
page must include a few lines of JavaScript code to enable breaching. Please contact your
BIS Liaison during design to discuss implementation.
Website statistics (Urchin)

Urchin 6.6 is the standard website statistics package provided for all websites. During the
design phase, the interactive agency should request and review a separate document called
the UTM Installation.doc to setup the standard tags. At a minimum, all pages on hosted
sites as well as co-branded sites should contain the standard tags. More advanced tracking
such as Flash interactions can also be tracked.
Urchin provides robust statistical tracking capability. It is not recommended for interactive
agencies to utilize other 3rd party capabilities (such as Google Analytics) without discussing
the requirements with the BIS liaison.

Internal Use Only
hosting security
Content delivery network

BIS is partnered with Internap for content delivery network (CDN) services. All interactive
agencies are strongly encouraged to utilize this CDN for large, static content (>100KB) on
any of the external-facing consumer websites, especially those websites that could
experience large spikes in traffic during highly visible promotions.
BIS will provide the interactive agency a separate document called Internap General Usage
Instructions as well as the necessary credentials for accessing the CDN if it determined to
be necessary during the initial hosting request discussion.
The usage of the CDN does introduce some complexity to the development process and
possibly additional charges. Thus, small sites with minimal traffic should discuss with BIS
usage of the CDN.
Internap is also providing optional video transcoding services in combination with CDN
hosting of the videos for an additional cost. This service helps deliver a standard user-
generated content (UGC) capability.
Hosting environment access

Protection of our digital assets is a key component of our Universal Hosting Environment. In
order to ensure the security of production and staging environments, agencies must submit
PepsiCo’s Hosting Access Request Form. Each developer will require a named ID, and
agencies are responsible for notifying PepsiCo of any changes to personnel. Passwords will
be required to be changed every 90 days.
In addition, the UHE firewall implements IP filtering. Only agency static IP addresses behind
a firewall will be granted access. DHCP assigned IP addresses are not allowed. This static
address is the agency outbound firewall address not the internal workstation address.

Internal Use Only
hosting security
Secure FTP (content)
 Supported client(s): Any standards-compliant for Secure FTP
 Internet Explorer is NOT a supported FTP client
Direct MS SQL connectivity, database setup and configuration

 Supported client(s): SQL Server Enterprise Manager
Direct MySQL connectivity, database setup and configuration
 Supported client(s):
o MySQL Administrator (preferred)
o PHPMyAdmin (non-preferred because credentials sent in clear text)
o MYSQL read/write databases required to use InnoDb table format.
Database general information
 The development agency provides the schema and data (preferably generated using
dump or backup utilities) to our hosting vendor.
 Hosting vendor creates the database and loads the data provided by the agency
 Hosting vendor supplies credentials to the agency for connecting to the database by
the web app and by each developer who requires access.
 Hosting vendor requires two business days’ notice for creation/configuration of new
databases.
ISO 20000 certification

ISO 20000 is the worlds’ first international standard for IT Service Management. It consists
of two distinct parts:
 The Specification : ISO20000-1 defines the requirements for a service provider to
deliver managed services.
 The Code of Practice: ISO20000-2 describes detailed best practices for the
processes defined within ISO 20000-1.

Internal Use Only
hosting security
Web application security process guidelines
A Web application security process can be implemented using four key guidelines:
1. Understand: Perform security audits and defect testing throughout the application life
cycle. Production applications are an obvious first place to implement regular audits and
analysis to determine security and compliance risk to an organization. At the same time,
do not forget that the application development life cycle is the breeding ground for the
defects that cause the risks. Performing security testing during the application
development life cycle at key points during the various stages from development to QA
to Staging will reduce costs and significantly reduce your online risk.
2. Communicate: After risks and security defects have been identified, it is imperative to
get the right information to the right stakeholder. Development needs to understand what
these vulnerabilities and compliance exposures are in development terms. This means
providing details around how the attack works and guidance on remediation. There are
several good sources both online and in security testing tools for developers. Similarly,
QA must be able to perform delta, trend and regression analysis on the security defects
just like they do for performance and functionality flaws. Using their existing methods
and metrics they, along with Product Management, can properly prioritize and monitor
the defect remediation process as well as accurately assess release candidacy. Finally,
with the ever-increasing number and scope of Government and internal regulations and
policies, teams from Security, Risk, Compliance, and Research & Development need to
communicate and validate application risks against these very real business drivers.

Internal Use Only
hosting security
3. Train: Ensure proper training of developers. This does not necessarily mean that with
training the code they write will be more secure. But the more developers understand
how web servers and browsers communicate and interact, and the protocols used in
Internet communications, the more likely they are to build applications that are not
vulnerable to attacks.
4. Measure: For any process to be successful, there need to be criteria by which to
measure the successes or failures of the procedures implemented. Organizations use
trending and defect remediation analysis metrics to identify areas and issues to focus on;
there might be a certain security defect type that keeps cropping up which can then be
identified and dealt with through targeted education and training to recognize repeated
risks with a particular infrastructure product or vendor. Ultimately, measuring and
analyzing scan results will contribute to a reduction in liability and risk brought about by.
Disaster recovery
A disaster recovery program is designed to provide for the rapid restoration of business
processes immediately following a natural or man-made emergency, or in the event of a
disaster, political turmoil, or criminal action. IT assets can only be resumed quickly with a
proper level of preparedness.
A “Vital” IT asset is an asset which directly supports or is a critical interface to a Vital

Business Process (VBP), without which the VBP would be unavailable for end-to-end
processing. A business process may be considered Vital if loss or delay in recovery would:
1. Result in a significant loss of assets or revenue flow, or;

2. Render PepsiCo unable to meet important commitments to customers or to protect
the interests of shareholders, or employees.
An asset is deemed vital by the Vital Business Process owner (BPO)

Internal Use Only
hosting security
Work product Hosting security checklist

work product Yes/No
. Is the hosting provider ISO 20000 certified?
What tools does the hosting provider use for network intrusion detection?
What tools does the hosting provider use for host intrusion detection?
What type of monitoring / alerting do you have in place in order to quickly
resolve an outage?
Is there any monitoring in place to gather usage statistics such as number of
users on the site, page views and concurrent sessions? Please describe the
data collection and reporting process?
Is there a disaster recovery plan in place?
Is external access granted into the hosting environment?
Are processes and/or systems in place to prevent outages?
Are processes and/or systems in place for activity auditing?

Internal Use Only
hosting security
References IBM developerWorks – http://www.ibm.com/developerworks
references

Internal Use Only
<TITLE PLACEHOLDER>
PepsiCo
STANDARD

mobile web development
Description ...................................................................... 7.8.3

contents Value ........................................................................................................................... 7.8.3
Area of use .................................................................................................................. 7.8.3
Detail .............................................................................. 7.8.4

Web application or native application .......................................................................... 7.8.4
Custom application development ................................................................................ 7.8.5
Mobile web development ............................................................................................ 7.8.6
Mobile web design ...................................................................................................... 7.8.7
References ..................................................................... 7.8.9

Internal Use Only
Description This standard provides a high-level set of guidelines for application

description development for major mobile devices such as the Apple iPhone,
Android, and BlackBerry, in addition to providing standard guideline
references for web-based mobile application development.
Value
This standard:
 Addresses compatibility with chosen platforms
 Provides references to the major wireless device platforms
 Explains differences between native and web-based mobile application development.
Area of use
Since mobile devices can differ in functionality and screen size, it is difficult to create a one-
size-fits-all set of standards and guidelines. Although this document provides high-level
guidance, it is highly recommended to refer to specific standards guides developed for
major market leaders such as Apple, Google, and BlackBerry. Links to these standards
guides include the following:
Google Android – http://developer.android.com/guide/index.html

Apple iPhone – http://developer.apple.com/devcenter/ios/index.action
BlackBerry – http://us.blackberry.com/developers/
Mobi Web Development – http://mobiforge.com/starting/story/dotmobi-mobile-web-
developers-guide

Internal Use Only
Detail Web application or native application

There are some general guidelines for deciding whether to develop a native application for a
detail mobile device or develop a web-based mobile application. In general, web applications
should be developed for mobile devices when the client wants to target a broad base of
wireless devices, and native applications should be developed when the client wants to
leverage device-specific functionality such as location-based services, the device’s camera,
or the device’s actuator. Although native applications expose greater functionality, a
separate application will have to be developed for each platform (Android, BlackBerry,
WebOS, iOS).

Internal Use Only
Custom application development

Device Functionality – Google Android devices range in a variety of screen sizes and
functionality including built-in cameras, actuators, and GPS. It is important to understand
what devices are being targeted when developing an Android application. Developers
should handle instances where device functionality may be limited such as GPS being
disabled or the device not having a camera.
Recommended:
Web Services – Web services should be REST based leveraging XML or JSON responses.
Out-of-the-box, Android does not come with the SOAP service client library such as Apache
Axis, but Android does come with a robust set of Apache.http libraries, XML parsers (Dom,
sax, XMLpull), and the JSON parser.
User Data – In general, user data should be kept on the on the device. If data collection is
necessary, the data should be encrypted before it is sent. A privacy policy should also be
added to the application indicating to the user what information is going to be transmitted.
Landscape and Portrait Modes – Applications should support both portrait and landscape
modes when appropriate. OpenGL games for devices such as Android or iPhone can
support either mode. Requirements should clearly state what modes and devices will be
supported including, but not limited to emerging tablet devices.

Internal Use Only
Mobile web development

Domain Allocation
XHTML-Mobile Profile 1.0 – All www.domain.mobi sites must have an xhtml mobile profile.
A device specific mark up language can be used, but the site should default to the XHTML
Mobile profile. If the site detects a desktop browser, it my send HTML 4/5 formatted pages,
but the site should default to XHTML Mobile profile if a mobile device is detected.
Note: .Mobi sites should be available at a second level domain and will not contain
frames.
Recommended – .Mobi websites should be available at http://domain.mobi. The website

should not require someone to enter www. as part of the address. The DNS should support
the www.domain.mobi and domain.mobi pointing to the same IP Address.
Required – The no frame rule in the Mobi registrant rules is probably the easiest rule to
comply with. Frames are not supported on many mobile devices, and using them may have
unpredictable results. Frames are also considered as being generally problematic on the
desktop web also, since they make a web document less accessible.
To ensure that your site is in compliance with this rule, ensure that the home page of your
site has no FRAME, IFRAME or FRAMESET elements in it.

Internal Use Only
Mobile web design

Navigation
The preferred and most common method of creating mobile navigation schemes is to use a
simple vertical list of options, often assigning and listing the corresponding numbers (0–9) to
the access keys for keypad navigation. You can design this list in many ways using style
sheets or images. You should consider supporting more advanced navigation methods for
higher-end phones to ensure a rich user experience on these devices. (see the .Mobi
Developers Guide p. 25)
Recommended:
Site Map – Create a simple site drill-down architecture, nesting content into well-labeled
categories. Drill down should not go more than five levels deep.
Linking Pages – Limit links on a page to 10. Assign access keys [0-9] to the links to ensure
compatibility with older phones and create easier navigation.
Link Prioritization – Place links that are popular or you want to receive more activity at
the top of the page. Less active links are placed lower. This creates an ease of use for the
end-user.

Internal Use Only
Presentation
It is highly recommended that devices or device types are identified before the design and
development phases. This helps determine the size of icons, images and screen sizes that
are being targeted. This may include creating custom content tailored for specific device
types or screen sizes.
Recommended:
XHTML-MP 1.0 – Standard presentation language for most modern mobile devices.
XHTML-MP 1.0 is based on XHTML-Basic, and most modern mobile devices can leverage
CSS mobile for style sheets to control page layout. For increased compatibility with a
broader range of wireless devices developers may also want to deploy equivalent WML
pages. Ready.mobi provides an excellent tool for checking mobile sites for XHTML-MP 1.0
compatibility.
Frames – Frames can be problematic for desktop browsers, but they are considered
unusable for mobile devices. Developers should avoid the use of frames and iFrames for
mobile development.
Plug-ins and Scripting – Plug-ins should be avoided since most devices including the
Apple iPhone do not handle plug-ins such as ActiveX, Adobe Air, and Adobe Flash.
Although devices such as the Apple iPhone and Android devices can interpret JavaScript,
mobile web apps should run reasonably well without the use of JavaScript. If more complex
scripting that is targeted for a specific device can be used then alternate, simplified pages
should be created for general mobile use.
Tables and Nested Tables – Due to the size of screen layouts, rendering inconsistencies
and established general best practices for web design, tables and nested tables should be
avoided in favor of style-based layouts.

Internal Use Only
Guides
XHTML-MP Best Practices – http://www.passani.it/gap/
references
References .Mobi Web Development – http://mobiforge.com/starting/story/dotmobi-mobile-web-
developers-guide
Google Android – http://developer.android.com/guide/index.html
Apple iPhone – http://developer.apple.com/devcenter/ios/index.action
BlackBerry – http://us.blackberry.com/developers/
Tools
Droid Draw – http://www.droiddraw.org/
XHTML-MP readiness – http://ready.mobi/launch.jsp?locale=en_EN
Android Eclipse Installation – http://developer.android.com/sdk/installing.html
Android Downloads – http://developer.android.com/sdk/index.html

Internal Use Only

Internal Use Only
<TITLE PLACEHOLDER>
PepsiCo

STANDARD

resource monitoring
Description ...................................................................... 7.9.3

contents Value ........................................................................................................................... 7.9.3
Detail .............................................................................. 7.9.4

Internal Use Only
resource monitoring
Description The Resource Monitoring Standard provides definitions and criteria

to monitor operating status for hardware and software resources
description associated with a digital project.
Value
The standard assembles in one place the information about monitoring norms for many
industry-standard resource types associated with web application development.

Internal Use Only
resource monitoring
Detail The Resource Monitoring Standard outlines definitions, criteria, and reference materials for
the monitoring of situations associated with filesystems, memory, CPU, processes, etc.
detail across an array of platform and operating system resources, such as:
 AIX  Windows
 HP-UX  Active Directory
 UNIX Adaptive  Apache
 Syslog  DB2
 URL monitoring  Oracle
 Windows OS  Unix OS
 RedHat Linux  MS Cluster
 SUSE Linux  MS Exchange
 Solaris  MS Exchange 2007
 AL SNMP RedHat  MS IIS
 AL SNMP SUSE  MS SQL
 AL WMI Windows  VMWare

Internal Use Only
resource monitoring
The Resource Monitoring Standard spreadsheet is available in a Microsoft Excel file on
The AIX resource monitoring worksheet is illustrated here. The spreadsheet also provides a
template to define monitoring criteria for other resource types.

Internal Use Only
resource monitoring

Internal Use Only
<TITLE PLACEHOLDER>
PepsiCo
STANDARD

web application security
Description .................................................................... 7.10.4

contents Value .................................................................................................................................... 7.10.4
Introduction .................................................................. 7.10.5
Scope of document .............................................................................................................. 7.10.5
Authority for document ......................................................................................................... 7.10.5
Document use and disposal ................................................................................................. 7.10.5
Ownership of document........................................................................................................ 7.10.5
Overview...................................................................... 7.10.6
Application security overview................................................................................................ 7.10.6
Application security goals ..................................................................................................... 7.10.7
Application security framework ............................................................................................. 7.10.9
Risk-based approach for application security ....................................................................... 7.10.9
Risk assessment considerations ........................................................................................ 7.10.11
Application security mechanisms ........................................................................................ 7.10.13
Design & development................................................ 7.10.14
Access controls .................................................................................................................. 7.10.14
ID standards ....................................................................................................................... 7.10.14
User names / passwords .................................................................................................... 7.10.15

Internal Use Only
Password standards ........................................................................................................... 7.10.19
User Access Management ................................................................................................. 7.10.24
Accounting and logging ...................................................................................................... 7.10.25
Protection against malicious code ...................................................................................... 7.10.26
Information systems development and maintenance .......................................................... 7.10.26
Authentication .................................................................................................................... 7.10.27
Authorization ...................................................................................................................... 7.10.31
Session Management ......................................................................................................... 7.10.34
Secure Coding.................................................................................................................... 7.10.35
Database Calls ................................................................................................................... 7.10.38
Cryptography ...................................................................................................................... 7.10.38
Infrastructure and Communication Security ........................................................................ 7.10.39
Patching ............................................................................................................................. 7.10.44
Application Testing ............................................................................................................. 7.10.48
Operations .................................................................. 7.10.50

Operational Procedures...................................................................................................... 7.10.50
Appendices ................................................................. 7.10.51
Appendix A: Third party service delivery management ....................................................... 7.10.51
Appendix B: Information exchange policies and procedures ............................................... 7.10.51
Appendix C: References..................................................................................................... 7.10.52
Appendix D: Recommended reading .................................................................................. 7.10.52

Internal Use Only
Description This standard outlines the minimum-security configuration standards

and procedures for securing enterprise applications. The PepsiCo
description Information Security Group (ISG) adopts Center of Information
Security Standards (CIS) for establishing and implementing
operating controls to manage information security risks.
Value
By ensuring that all information systems meet the same minimum security hardening standards,
PepsiCo can ensure the protection of its information assets against known threats and
vulnerabilities. Additionally, by ensuring uniform hardening, the Information Security Group can
quickly analyze any new or emerging threats to determine the possible exposure of PepsiCo
information security assets and develop an appropriate remediation response:

Internal Use Only
Introduction This document provides a summary of the minimum configuration requirements for security
hardening of enterprise applications in use by PepsiCo. These requirements are based upon current
technologies, known and anticipated vulnerabilities, and threats. These requirements may change
introduction as technology and threat landscape evolve. This document assumes applications are installed on
hardened operating systems.
Scope of document
This procedure defines the minimum requirements and directives for infrastructure security
hardening for the following applications:
 Applications currently in use on the PepsiCo network.
 Applications that do not adhere to the new standard set forth in this document may continue
to be attached to the network. A remediation plan and timeline must be developed and
approved by the Security Council.
 This document does not address operating system specific hardening and assumes
applications are installed on hardened and secured operating systems.
Authority for document

This document identifies both mandatory requirements and Information Security recommendations.
Document use and disposal

This document is for PepsiCo Internal Use only and must be used and disposed of in accordance
with this designation in the Information Classification Standard of the PepsiCo Information
Security Policies.
Ownership of document
Ownership and maintenance responsibilities for this document belong to the PepsiCo Information
Security Group (ISG). Please contact ISG by emailing DL - BIS Security Working Group.

Internal Use Only
Overview Application security overview

About application security
overview Wherever a person or system interacts with, or has the opportunity to interact with a web application,
there is a threat / risk opportunity for applications and information to be compromised.
The benefits of Web Applications including global accessibility, open source and rapid development
opportunities increase these threats exponentially:
Application Security is about securing the business data (for confidentiality and integrity) and its
accompanying infrastructure (files, databases, mail / ftp servers, etc.). Lack of security awareness
and deadline force developers to focus only on the functionality completeness, overlooking the
security aspects of the code. Application attacks comprise the majority of recent security attacks.
These attacks are not only common, but also severe. If an application has security vulnerabilities, it
can allow an attacker to access privileged data, delete critical data, and even break into the system
and operate at the same priority level as the application—giving the attacker the power to destroy
the entire system. Securing the network, OS, and server but neglecting to secure the application is
like building a luxury palace, but leaving its main gate open and unguarded.
This could be a serious concern for the application stakeholders as the recent standards and laws
such as PCI Data Security Standard, Sarbanes Oxley Act, etc. focus more on mandating application
security. To reiterate: there have been more security vulnerabilities reported in applications
compared to network and network related components in the recent days.

Internal Use Only
Application security goals

Security requirements
An application may have a large number of security related requirements, but they generally fall into
one of three categories:
 Confidentiality – Applications are centered on the data that they accept, manipulate, and
present. A secure application must ensure that only authorized users may access the data.
 Integrity – The data that an application accepts as input and provides as output, as well as
the range of actions taken based on this data, must be correct and not susceptible to
corruption or malicious editing.
 Availability – An application must be available at all appropriate times. The application must
be robust under denial of service type attacks by rejecting any input data that is clearly
invalid under its design parameters in the most highly efficient fashion possible.
Understanding the threat

A threat to an application is any circumstance or event that may potentially harm a service, whether
it is in the form of destruction, disclosure, modification of data, or denial of service. The people that
look to exploit these threats come from several groups with different agendas. They may be amateur
hackers, professional hackers, disgruntled employees, criminals, or cyber terrorists:
Goals of Application Security

Confidentiality Integrity Availability
Interception Modification Interruption

Eavesdropping Modification of user data Killing of user threads
on the Network Modification of message Flooding machine
Threats
Theft of information from the server traffic in transit with bogus requests
Information about the network Modification of memory Isolating machine by

configuration DNS attacks
Consequences Loss of information Loss of information Disruption

Countermeasures Encryption, Web Proxies Cryptographic Checksums Difficult to prevent

Internal Use Only
Application security principles
These principles are fundamental to all secure application development:
 Security should be seen as an integral part of the application design process and not as an
afterthought.
 ―Security through obscurity,‖ or relying on others not knowing what you are doing, is a highly
unreliable security practice.
 Simplicity of application design simplifies the application of security.
 All input is to be distrusted, even when coming from trusted systems.
 All entities in the system should be granted the least level of privilege required to accomplish
their necessary tasks.
 When an error is encountered, ensure that the system fails in a secure manner.
 Force all permissions in the system to be explicitly granted or else be denied.
 Any and all output must be sanitized to prevent information disclosure or relayed attacks.
 Application segmentation is a useful technique to limit an attacker‘s range of action.
 Multi-layered security models reduce the impact of individual security bypasses.

Internal Use Only
Application security framework

In-depth defense for application security
Security controls must be implemented at different layers within the system. The overall security
could be considered as ―Layers‖ of stacked controls as shown in figure below:
Alternatively, the intent is to increase ―work factor,‖ which is defined as the effort required by an
intruder to compromise one or more security measures. An architecture with a high work factor is
difficult to break into, while one with a low work factor can be compromised relatively easily. The
architecture implements security related controls at each layer including;
 Application Security Architecture
 Policies
 Standards / Procedures
 Training and Education
 Technology and Testing
 Monitoring and Enforcement
 Metrics for Continuous Improvement X

Internal Use Only
Risk-based approach for application security

The selection and specification of security controls must be based on risk associated with the
application and for overall management of risk - that is, the risk to organizational operations and
assets, individuals and other organizations. The risk-based approach to security control selection
and specification considers effectiveness and efficiency. Following are application impact definitions
and associated categorization based on adversity of impact.
1. The potential impact is LOW if: The loss of confidentiality, integrity, or availability could be
expected to have a limited adverse effect on organizational operations, organizational assets, or
individuals. A limited adverse effect means that, for example, the loss of confidentiality, integrity,
or availability might: (i) cause a degradation in mission capability to an extent and duration that
the organization is able to perform its primary functions, but the effectiveness of the functions is
noticeably reduced; (ii) result in minor damage to organizational assets; (iii) result in minor
financial loss; or (iv) result in minor harm to individuals.
2. The potential impact is MODERATE if: The loss of confidentiality, integrity, or availability could
be expected to have a serious adverse effect on organizational operations, organizational
assets, or individuals. A serious adverse effect means that, for example, the loss of
confidentiality, integrity, or availability might: (i) cause a significant degradation in mission
capability to an extent and duration that the organization is able to perform its primary functions,
but the effectiveness of the functions is significantly reduced; (ii) result in significant damage to
organizational assets; (iii) result in significant financial loss; or (iv) result in significant harm to
individuals that does not involve loss of life or serious life threatening injuries.
3. The potential impact is HIGH if: The loss of confidentiality, integrity, or availability could be
expected to have a severe or catastrophic adverse effect on organizational operations,
organizational assets, or individuals. A severe or catastrophic adverse effect means that, for
example, the loss of confidentiality, integrity, or availability might: (i) cause a severe degradation
in or loss of mission capability to an extent and duration that the organization is not able to
perform one or more of its primary functions; (ii) result in major damage to organizational assets;
(iii) result in major financial loss; or (iv) result in severe or catastrophic harm to individuals
involving loss of life or serious life threatening injuries.

Internal Use Only
Risk assessment considerations

The following considerations must be included during risk assessment process:
 Policy / Regulatory-Related Considerations - Information Processed, Stored or
Transmitted: Security controls that address matters governed by applicable federal laws,
executive orders, directives, policies, standards, or regulations (e.g., sensitive user data such
as health records, prescription and payment histories, personally identifiable information
(name, date of birth, Social Security Number), credit card numbers, and application
username / password web applications must comply with the following standards and
regulations where applicable privacy impact assessments) are required if the employment of
those controls is consistent with the types of information and information systems covered by
the applicable laws, executive orders, directives, policies, standards, or regulations.
Thus, the following must be considered:

 Information Processed: Does the information processed by the application contain
financial, confidential, credit card and/or personal (including PPI, PHI, and ePHI)
information?
 Information Stored and/or Transmitted: Does the information stored or transmitted by the
application contain financial, confidential, credit card and/or personal (including PII, PHI, and
ePHI) information?
 Security Objective-Related Considerations: Applications requiring a subset of controls
such as only one or two of the confidentiality, integrity, or availability security objectives may
be downgraded to the corresponding control in a lower baseline. Make a careful analysis to
ensure that the decision does not adversely affect the level of protection for the security-
relevant information within the information system.
 Technology-Related Considerations and Interconnectivity with PepsiCo Infrastructure,
Databases, and Applications: Security controls specific to technologies (e.g., wireless,
cryptography, public key infrastructure) are applicable to technologies that are employed or
are required to be employed within the information system. If externally hosted, consider
connectivity with PepsiCo internal network and infrastructure. Include type of connectivity,
strength of encryption, firewalls, and associated rule sets, platform, database, web engine,
and O/S.

Internal Use Only
 System Component Allocation-Related Considerations: Security controls in the baseline
represent a system-wide set of controls applicable to component within the system. Security
controls are applicable to the components of the information system that provide or support
the security capability addressed by the control and are sources of potential risk being
mitigated by the control.
 Common Control-Related Considerations: Security controls designated by PepsiCo as
common controls must be applicable to all applications regardless of whether they have
internal or external components in development and/or hosting. Common controls may affect
the responsibilities of individual information system owners with regard to the implementation
of controls in a particular baseline. Capability and expertise of implementing these controls
will impact risk profile.
 Application Development and Hosting Entity Considerations: Is this application being
developed and hosted internally or externally? If hosted externally, consider the size of the
organization, its previous experience with PepsiCo, and security profile.
 Nature of Web Application: Are web pages static or dynamic in nature? Is the information
provided from these applications static in nature or does it request, manage, store, and
transmit financial, personal, and confidential information (including PPI, PHI, and ePHI)
information?
 Existing Security Profile: Review policies, standards and procedures that are in place to
manage infrastructure, databases, and platforms. Include patching status and process,
security hardening baselines, Access Controls, Security measurement, and Monitoring
activities.

Internal Use Only
Application security mechanisms

The following Security mechanisms can be applied to implement the Application Security principles:
 Access Controls – used to establish account management access including segregation of
duties, login attempt control, and concurrent session controls
 Authentication – used to identify the user interacting with an application
 Authorization – used to determine if a user is allowed to do what has been requested
 Session Management – used to keep track of the user for future requests
 Secure Coding – used as reference to minimize application security vulnerabilities
 Cryptography – used to keep private data confidential
 Configuration Management – used to ensure that systems, platforms, web servers, and
applications have been configured according to information security baselines
 Audit and Accountability – used to ensure that applications and contracts have the capability
to maintain transaction records as well as provide the capability to audit external party
engaged to develop the application
 Data Validation – used to prevent many malicious user attacks on the application
 Error Handling – used to handle unexpected problems
 Logging – used to track what an application does
 Awareness and Training – used to establish secure code development practices as well as
end-user awareness and education

Internal Use Only
Design & Access controls

design &
development
Access control standard
All access controls must comply with PepsiCo standards. Check with ISG for the latest standards.
development All passwords and ID Administration must comply with Access Control Standard of the PepsiCo
Information Security Policies. Specifically:
Associates shall display a banner on PepsiCo's operating systems and network equipment
during login, if system software allows. Following is a PepsiCo-approved login banner:
―THIS SYSTEM AND ALL RELATED INFORMATION ACCESSED THEREBY ARE THE
PROPERTY OF PEPSICO, INC., AND ARE FOR THE SOLE USE OF THOSE PERSONS
EXPRESSLY AUTHORIZED BY PEPSICO. CONTINUED USE OF THIS SYSTEM IMPLIES
CONSENT TO MONITORING AND AN UNDERSTANDING THAT RECORDING AND/OR
DISCLOSURE OF ANY DATA ON THE SYSTEM MAY OCCUR AT PEPSICO'S
DISCRETION."
Associates may change the text to suit regional language and legal requirements, as
appropriate.
ID standards
ID creation shall follow PepsiCo's approved naming conventions, where applicable.
Naming Convention (Admin ID)

 Display Name: <Last>, <First>
 Short User Name: first initial plus the last name, up to a total of 8 characters
 Syntax: FLLLLLLL
NOTE: In case of collisions, a sequential number is appended to the end, deleting any necessary
characters from the name to not exceed 8 characters in total.

Internal Use Only
Naming Convention (Application ID)
 Full and Display Name: <Application Acronym> <long name or description>
 Short User Name: <Application Acronym> <long name or description>
 Syntax: Application acronym must match the acronym used in the Contacts Database
Naming Convention (Service ID)
 Display Name: Service <Description>
 Short User Name: SVC <Description>
Each ID is assigned to an individual, application team or a group.
At a minimum, an annual review of non-privileged IDs is required the 1st quarter of each year.
Information Owners or designee(s) shall review administrative access privileges at least once
every 180 days.
Password creation shall follow PepsiCo approved password standard. See Section 8.4 below
User names / passwords

To provide a secure password management system, web applications must meet several key
security objectives. These objectives include:
 Use of strong credentials
 Secure handling of credentials (both in transit and in storage)
 Prevention of information leakage
 Protection against brute-force attacks
 Protection against misuse of the Password Change function
 Protection against misuse of the Password Recovery function, and
 Use of proper logging and notification
User Password Requirements and Platforms
See table on the following page.

Internal Use Only
Table of User Password Requirements by Platform
History Failed
Platform Characters Expiration Consists of (password Inactivity Attempt Mitigating Control
remembered) Lockout
AS400 At least 8 90 days Case, letters, 12 60 5 None Required

numbers or
complexity enabled
(3 out of 4)
Mainframe At least 8 90 days Numbers, letters 4 No Setting 5 Execute script that evaluates and auto disables
(ACF2) logons after 60 days of inactivity.
Mainframe At least 8 90 days Numbers, letters, 12 60 5

(RACF) security level
UNIX At least 8 12 weeks No complexity No setting 70 b Daily Syslog failed login report.
(Solaris) enforcement
Distribute advisory to users to remind to users
capabilities
regarding complexity and password history.
Windows At least 8 90 days Complexity enabled 12 No setting 5 Monthly report generated that identifies accounts not
used in 60 days. Accounts manually disabled.
UNIX (AIX) At least 8 12 weeks Complexity enabled Histsize=12 No setting 5 Run script that identified inactive accounts. Accounts
manually disabled.
Oracle At least 8 90 days Complexity enabled 12 67 5 None

(73 if grace
period enabled)
LDAP At least 8 90 days No complexity 12 No setting 5 Distribute advisory to users to remind to users
enforcement regarding complexity and password history.
capabilities
Other Apps At least 8 90 days Complexity enabled 12 60 5 SERF if not compliant.
SAP At least 8 90 days SP1 – No setting 5 No setting 5 Execute program that evaluates and auto disables
logons after 60 days of inactivity and password
SP4 – Complexity
history.
enabled (letter,
numbers, specials)
VAX At least 8 90 days Numbers, letters 12 No setting 5 Execute script that evaluates and auto disables
logons after 60 days of inactivity.

Internal Use Only
Table of Service Password Requirements and Platforms
See also, additional requirements after this table.
Review
Platform Characters Consists of Mitigating Control
Frequency
Mainframe At least 8 Numbers, Letters Annually None

(ACF2):
Mainframe At least 8 Numbers, Letters Annually None

(RACF):
UNIX At least 15 No Complexity Annually Distribute advisory to administrators to

(Solaris) capabilities remind users regarding complexity and
password history.
Windows At least 15 Complexity enabled Annually

Restrict to specific devices as possible.
Non-interactive and for local logon only.
UNIX (AIX) At least 15 Complexity enabled Annually None
Oracle At least 15 Complexity enabled Annually None
LDAP At least 15 Complexity enabled Annually None
Other Apps At least 15 Complexity enabled Annually None
SAP At least 15 SP1 – No setting Annually Distribute advisory to administrators to

remind users regarding complexity and
SP4 – Complexity
password history.
enabled (letter,
numbers, specials)
VAX At least 15 Numbers, letters Annually Non-interactive and for local logon only.
AS400 At least 15 Case, letters, numbers Annually None

or complexity enabled
(3 out of 4)

Internal Use Only
Additional service password requirements:
 Disallow hard-coded passwords in software.

 Passwords shall be stored in an encrypted or hashed format
 Default passwords used for software or hardware installation or maintenance procedures
must be changed or disabled.
 Authentication process must be designed to prevent repetitive attempts to compromise
authentication credentials.
 An ID shall be temporarily disabled after three consecutive invalid password authentication
requests for minimum of 15 minutes.
 PepsiCo authentication failure messages shall not indicate the source of the failure.
 An example is the message ―
incorrect login," not ―
incorrect password.‖
 Application left unattended or inactive shall be logged off or locked within a period not to
exceed 10 minutes and require a password to resume processing.
 Suspend inactive authentication accounts after 90 days.
 Delete inactive authentication credentials after a maximum of 400 days.
 If the application is assigning usernames, it must do so in such a manner so as to avoid
obvious correlation between a username and the actual name of the involved user.
 Application must ensure that usernames are unique.
 Allow only A..Z, a..z, and 0..9 for construction of usernames. If special characters such as
apostrophe and @ are allowed, make sure they are properly escaped.

Internal Use Only
Password standards
Password length
 All passwords must have at least 8 characters.
 The application must not allow blank passwords.
 The application must not enforce a maximum length on passwords.
 Users should be encouraged to choose long pass phrases.
Password complexity
Passwords must be case-sensitive, and all passwords must have at least two of the following three
types of characters:
 At least one upper case alphabetical character
 At least one lower case alphabetical character
 At least one numeral
The application should enforce password quality controls such that the password cannot contain:
 The user‘s name (first, middle, or last)
 The account‘s userid
 The portion of the user‘s email address before the @ symbol
 The user‘s challenge question or secret answer
 Spaces or non-English characters.
 Passwords must not include the company name (PepsiCo, Frito Lay, etc.)
 Passwords must not have more than 3 of the same character
 Repeating characters in a password are not allowed (example: aaa, ggg, etc.)
 Sequential characters in a password are not allowed (example: abc, xyz, etc.)
To ensure additional password strength, the use of common words, common names, and commonly
chosen passwords must be disallowed. This can be accomplished via a local dictionary of such
common words and phrases.
Password history
 The user must be prohibited from reusing any of their previous 8 passwords.
 The password history must consist only of hashes of previous passwords, and never their
original, clear-text form. Also see password hashing requirements.

Internal Use Only
Password expiration
 Users must be forced to change their passwords every 90 days.
 If mandatory password expiry is not an option (e.g., owing to usability concerns), consider
giving users the option to have their passwords expire every 90 days.
Password minimum age
Each password must have a minimum age (in days) before the user can reset it. Password minimum
age must always be at least one day. The minimum password age must be less that the password
expiration date. In conjunction with password history, the minimum password age prevents users
from easily reusing old passwords.
Temporary account suspension after unsuccessful login attempts

 After five unsuccessful attempts to enter a password within 60 minutes, the involved
username must be suspended for at least 15 minutes, even if a valid password is entered.
 The application should never indicate that any specific account has been suspended. Nor
should it reveal the details of the lockout policy.
 If an account is suspended, then login attempts will be rejected without even checking the
credentials.
Displaying and printing of passwords
 The display and printing of passwords must be suppressed so unauthorized parties will not
be able to observe or subsequently recover them.
 Never send the password hash or password clear-text to any user in any form, e.g., in an
email or via the browser.
 If the user forgets his password, he must not be allowed to recover the existing password.
 The application must not implement any function, page, or report that retrieves passwords
from the server.

Internal Use Only
Protection of passwords in transit over the network
 Unencrypted passwords must not be emailed to the application users.
 The application must deliver its login form to the user‘s browser over HTTPS to allow the
user to verify the authenticity of the login page.
 The application must submit the login form over HTTPS using the HTTP POST method.
 Username / passwords must never be included in URL query string parameters, even if the
credentials are encrypted or if HTTPS is being used. Credentials end up in query string
parameters when the application submits the login form using GET requests or uses
Javascript URL redirects when submitting the credentials. This is a risk because query
strings are logged by proxies and web servers and are visible in the browser.
Storage of Passwords
 Passwords will always be stored in hashed form and never in their original, clear-text form.
Use of SHA1 in 246 bit mode is recommended for proper and strong hashing.
 Use a password salting mechanism as part of the hashing process. The salt values must be
protected.
 Passwords must never be hard-coded into software.
 Username / passwords used to access other systems (database, directories, etc.) must be
encrypted in accordance with standards.
 Username / passwords must not be stored in HTTP cookies or URL parameters, even in
encrypted form or when using HTTPS.
Password change functionality
 The application must have a change password feature.
 The functionality must be accessible only to authenticated users.
 The application must ensure that a user can change only his password and not another
user‘s, e.g., by tampering with the username parameter in HTTP request.
 The password change form must include fields the old password, the new password, and
confirmation of the new password.
 For all three password HTML fields, use AUTOCOMPLETE=OFF to prevent browsers from
caching the passwords locally.
 If the user gets the old password wrong 5 times, the application must lock the account and
kill the session.

Internal Use Only
Forgotten password functionality
 If the application provides an online method for letting users reset their forgotten password,
the method must follow one of the following two mechanisms:
o Send a unique, un-guessable recovery URL to the email address the user provided
during registration. The user must visit this URL within a few minutes to set a new
password, or
o Allow users to answer their at least 2 challenge questions with a secret answer.
 Alternative reset methods (whether online or admin-assisted) must be approved,
secure methods.
 Using a ―
Password Hint‖ mechanism is highly insecure and must not be used.
 If the recovery URL approach is used, the application will send the URL only to the email the
user provided during registration. The application must not enable a hacker to receive the
recovery URL at an email address of his choosing, either by asking for the email during the
recovery process or by including the user‘s email in cookies or other HTTP parameters
where they can be easily altered.
 If the challenge question approach is used, the possible questions must be selected from a
pre-approved list of questions. Any variation from these questions must receive approval before
use. Answers to questions must be stored in salted hash form, and never as plain text.
 A users must not be allowed to set his secret answer to be the same as his username,
password, or to the corresponding challenge question.
 Accounts must be suspended temporarily following 5 failed attempts to complete the
challenge.
 The application must never display the existing, forgotten password to the user after
successful completion of the challenge.
 The application must notify users via email after their passwords have been reset.
 To prevent the Forgot Password functionality from being vulnerable to username
enumeration attacks, use the following generic message on the forgotten password form
where the user enters their username (or email): ― If you entered a valid email address, you
will receive an email with further instructions. If you don't receive an email in the next xxx
minutes, it is likely you mistyped your email address, or you don't have access to this
application. Try again, making sure you enter it correctly.‖

Internal Use Only
Remember me functionality
Remember Me functions allow users to conveniently access the web application without having to
supply their credentials each time they access the application from a specific computer. These
functions are often highly insecure by design. It is recommended that critical applications avoid
implementing this function. Otherwise, if the application does choose to provide this function, the
design and implementation must receive proper approval.
Handling incorrect passwords

 In case of login error, the application must not disclose the part of the credentials that were
invalid. Instead it must display a generic message to the user, such as, ― Unable to login.
Username or password is incorrect.‖
 The application must log all authentication attempts, especially failed attempts.
Logging and notification
 The application must log all failed and successful authentication-related events, including
login, logout, password change, password reset, account suspension, and account recovery.
 The log entries must contain non-secret details such as IP address and username, but never
security secrets such as passwords and answers to secret questions.
 Logs must be strongly protected from unauthorized access.
 The application must send an email to the user‘s registered email address whenever his
password changes. The email must not include their username or password.
 After a user logs in, display his most recent login time and location and also the number of
invalid login attempts made since then, e.g.:
―You last logged in on May 1, 2008 at 12:22 PM, 12 days and five hours ago, from
11.12.12.12 (some.server.ng) apparently located in Chicago. Two invalid login
attempts were made since then.‖
This kind of display allows a user to notice that someone is silently accessing his account
and if his account is being subjected to password-guessing attacks. This will make the user
more likely to change his password frequently and to a strong value. If possible, display the
last three to five logins, and provide an interface to view the data historically. The application
must log all failed and successful authentication-related events, including login, logout,
password change, password reset, account suspension, and account recovery.

Internal Use Only
User Access Management

Adhere to the following:
 Identify all information related to the business applications and assign the appropriate asset
and data classification, per section 6.2 of the PepsiCo Information Security Policies
 Document a formal authorization procedure to control the allocation of access rights to the
application.
 Implement a formal user provisioning and de-provisioning process for standard and
privileged level access rights to application.Authentication – used to identify the user
interacting with an application
 A special provisioning procedure should be in place, where appropriate, addressing the need
to control the allocation of privileged access rights, which allow users to override system
controls (i.e. Firecall).
 Ensure requirements for segregation of access control roles, e.g. access request, access
authorization, access administration.
 Annual certification of user and service accounts.
 Perform bi-annual certification of privileged access accounts.
 Disable shared or anonymous accounts.
 Unique user IDs to enable users to be linked to and held responsible for their actions; the
use of group IDs should only be permitted where they are necessary for business or
operational reasons, and should be approved and documented.
 Ensure information is accessible only to authorized individuals.
 Authentication information must be protected during storage and transmission with
appropriate confidentiality controls.
 Authentication is required for access to application.
 All access to the application must be performed via secured protocols.
 PepsiCo administrator passwords shall be changed immediately upon suspecting or knowing
someone has compromised the system, or if an associate with knowledge of the password
terminates from PepsiCo.

Internal Use Only
Accounting and logging

Adhere to the following requirements:
 Synchronize system clocks to ensure log accuracy. Application access shall log, at a
minimum, the following:
o Date / time
o Request status
o Terminal / node ID
o Associate authentication credentials
o User activity (e.g., failed login attempts)
o System activity (e.g., unexpected reboots)
o Program-specific log file activity (e.g., excessive or unusual file transfers)
o Log failed and succeeded access attempts.
 Maintain audit logs of critical security events.
 Implement centralized audit-logging scheme, where possible, to securely store audit logs.
 Implement access control to protect audit logs and records against tampering (e.g., deletion
or alteration).
 Restrict privileged accounts from access to the audit logs, audit records, and audit
configurations.
 Ensure there is sufficient system storage so log files are not overwritten.
 Retain audit logs for a minimum of 30 days.
 Comply with PepsiCo Retention Policy -
https://www.mypepsico.com/ep/corp/Policies/policy15.htm

Internal Use Only
Protection against malicious code

Install and regularly update malicious code detection and repair software, where appropriate, to scan
computers and media as a precautionary control, or on a routine basis; the checks carried out
should include:
 Check any files on electronic or optical media, and files received over networks for malicious
code before use.
 Check electronic mail attachments and downloads for malicious code before use. This check
should be carried out at different places, e.g. at electronic mail servers, desk top computers
and when entering the network of the organization.
 Check web pages for malicious code.
Information systems development and maintenance

PepsiCo applications shall implement input data validation, including:
 Dual input or other input checks, such as boundary checking or limiting fields to specific
ranges of input data, to detect the following errors:
o Out-of-range values
o Invalid characters in data fields
o Missing or incomplete data
o Exceeding upper and lower data volume limits
o Unauthorized or inconsistent control data
o Protection against attacks using buffer overruns/overflows
o The use of add, modify, and delete functions without proper authorization
 Periodic review of the content of key fields or data files to confirm their validity and integrity
 Procedures for responding to validation errors
 Procedures for testing the plausibility of the input data
 Defining the responsibilities of all personnel involved in the data input process
 Creating a log of the activities involved in the data input process

Internal Use Only
Authentication
The application must not be susceptible to authentication circumvention.
Handle credentials securely

Ensure that all credentials are created, stored, and transmitted securely so as to avoid unauthorized
disclosure
Load login form using HTTPS

Ensure that the login form itself is loaded using HTTPS, rather than just switching to HTTPS when
submitting the form.
Submit login credentials using POST over HTTPS

Never submit login information via GET requests, even when using HTTPS. Instead, always use
POST over HTTPS. GET requests can potentially be stored in browser histories, caches, and
bookmarks.
Secondly, when the client navigates to a new website, the browser could send the URL containing
the credentials to the new site via the HTTP REFERER field. Finally, intermediary systems such as
firewalls and proxy server could log the GET requests. Anyone with access to these logs can read
the URL and use it in an attack
Submit sensitive data over POST

Never use URL query strings to pass information between pages that contain sensitive information
or access privileged functionality. Information in query strings is directly visible in the browser‘s
location bar and is stored in logs by web servers. Sensitive information (such as usernames, SSN‘s,
SQL queries, etc) can be used by attackers in various ways to attack the application.
For example, SQL queries can reveal table names and can easily be edited in the query string to
attack the backend database and view or edit data. A safer, though imperfect, alternative for passing
sensitive information is the POST method. Data submitted over POST is not visible in the browser‘s
location bar and is not logged by web server. POST data can be sniffed off the network, however,
and must therefore be encrypted when used for submitting confidential data.

Internal Use Only
Report user authentication activity
After the user logs in, display his most recent login times and locations including following:
 Login Activity: ―You last logged in on September 22, 2008 at 11:24 PM, four days and two
hours ago, from 10.22.22.21 (some.server.ng) apparently located in Mali‖. NOTE: If possible
display the last three to five logins, and provide an interface to view the data historically.
 Display User Activity:
o a) viewed your XXXXXXXX
o made changes to YYYYYYYYY (this will help them refresh their memory if they
cannot remember if they've really logged in those days or not)
This kind of display allows a user to notice that someone is silently accessing his account.
Avoid use of basic and digest authentication
With Basic Authentication, the browser transfers password information to the web server in Base-64
encoded form, rather than in encrypted form. An attacker who is monitoring the network traffic can
capture the credentials and easily decode the password. Digest Authentication solves this main
problem with Basic Authentication by applying cryptographic hashing to the user credentials.
Neither scheme provides logout capabilities.
The data and credential privacy concerns of the two schemes can be mitigated by using HTTPS.
The security community, however, considers both types of authentication on the weak end of the
security spectrum and recommends against their use [2].

Internal Use Only
Use fail-safe login mechanisms
A fail-safe (aka fail-closed) login mechanism is one which by default denies access to users when
exceptions or error conditions occur during the login process. Fail-open mechanisms, on the other
hand, allow access by default, thereby permitting unauthorized access to the application should an
exception or error condition arise. Consider the following simplified login method:
public boolean doLogin(String username, String password) {
try {
User user = getUser(username, password);
if (user == null) { //supplied user credentials were invalid
return false;
} catch (Exception e) {
//ignore
return true; //allow by default - BAD!

Internal Use Only
This is an example of a login method that fails-open. Suppose the getUser() method-call generates a
NullPointerException because the username is null. The login will be successful. As a consequence,
even though the resulting logged in session will not be tied to a specific user identity and role, the
malicious user will have access to some, if not all, authenticated functionality.
The secure approach is to deny access by default and to specifically identify the conditions under
which access is allowed [10]:
public boolean doLogin(String username, String password) {
try {
User user = getUser(username, password);
if (user) { //supplied user credentials are valid
return true;
} catch (Exception e) {
//ignore
return false; //deny by default – GOOD!

Internal Use Only
Do not expose work in progress / staged sites to public
Work in progress and staged sites are in various stages of completion and do not have appropriate
security controls. Exposure of these to public poses a significant security issue. Never exposure
such sites / work to public.
Restrict access to audience

Restrict sites to ―
Need to Know‖ basis. Unless a site needs to be open to the public access must be
restricted from selected IP addresses which have been identified to require access to this
information.
Stream data to internal clients

Do not extract data to flat files on the web servers for the users to browse. The same precaution
must be taken for the log files. Instead, data must be streamed to internal clients.
Authorization
The application must not be susceptible to authorization circumvention. Application business logic
must be written with proper authorization controls such that user access to restricted resources and
actions is based on the user‘s identity and roles. The application must not permit users to access
data for accounts other their own. The application must restrict access to personal data to those who
have a business purpose to view or use it.
Adhere to the principle of least privilege

Every process or transaction should execute with the least set of privileges necessary to complete
the job. This approach reduces the chances of malicious pieces of code running with elevated
privileges.
 Web application servers will run under accounts with minimal privileges. They will never
execute as ―
Administrator‖, ― root‖, ―
sa‖, or any other privileged account.
 Database accounts used by web applications will not have more access privileges to the
database than is required to implement application functionality. Use limited accounts that do
not have schema-modification privileges unless required.
 Utilize J2EE and .NET platforms‘ capabilities to limit the privileges of the application code
running inside their virtual machines.

Internal Use Only
 User accounts should be created unprivileged and then given permissions incrementally until
they have the full capabilities required.
 Business user accounts should not be administrator accounts and vice versa. If the same
user needs both levels, separate accounts should be created.
 Development, test, and staging environments must be set up to function with the lowest
possible privileges so that production will also work with the lowest possible privileges.
 Database access should be performed through parameterized stored procedures (or similar)
to allow all table access to be revoked (i.e., select, drop, update, insert, etc.). This should be
done using a low privilege database account, which does not hold any SQL roles
above ― user.‖
Centralize all authorization routines
Minimize the use of custom authorization routines, instead use built-in platform or framework
authorization facilities.
If you are not using built-in framework authorization facilities, ensure that your customized
authorization routines are centralized.
If you are not using built-in framework authorization facilities, then ensure that calls to your
centralized authorization routines are placed at the beginning of each protected resource view or
action. This will help prevent unauthorized access to sensitive resource and action URLs that might
have been guessed by users.

Internal Use Only
Control access to protected resources
The application must enforce access control for each site function and data.
 Use logical tier separation and patterns such as Model-View-Controller instead of directly
accessing protected resources from the web tier.
 Ensure that model code checks that the requesting user should have access to the protected
resource.
 Ensure that the code requesting the resource has adequate error checking and does not
assume that access will always be granted. Failure cases should be accounted for.
Avoid use of client-side tokens
Do not trust any client-side authentication or authorization tokens in headers, cookies, hidden form
fields, or in URL arguments unless they have been cryptographically secured via signing or
encryption.
Authentication
Authentication Tokens: Authentication tokens created by PepsiCo code to authenticate one server
to another should only work between short time range (to allow for clock differences between
servers). These tokens must be restricted to ―
one‖ use during that time range. Tokens should utilize
variable length when possible.
Passwords: Instead of managing local passwords on web-based systems, where possible

authenticate GPIDs on outward facing servers inside PepsiCo, and let the external web server map
roles to authenticated GPIDs.

Internal Use Only
Session Management
Use built-in frameworks
 Use a robust, well-know session manager built into the web application framework.
 Use the most up-to-date version of the session management framework for your platform.
 Monitor security mailing lists and vendor security announcements to stay apprised of any
weaknesses that might have been found in the session management framework.
Maintain Session State on the Server Only
The application must maintain all user session state (authentication, authorization, and role data) on
the server only. For user authentication and authorization, the application must not rely on any data
stored on the client other than the session identifier. Session state must be tied to a specific browser
session through the use of session cookies. If it is unavoidable to store some session data on the
client, the application must encrypt that data strongly during round trips between the server and the
client. Additionally, hidden fields should not be used to pass sensitive state information between the
browser and the server, unless the sensitive information is encrypted during transit.
Do Not Span Sessions over Protected and Unprotected Resources

For protected parts of the application, use HTTPS to transmit session identifiers, and do not reuse
session identifiers that were initially transmitted for unprotected resources in clear via HTTP, thereby
increasing the risk of session hijacking. If the session identifier was initially transmitted over clear
HTTP, an additional session identifier must be used for secure parts of the application.
Destroy Session Tokens on Logout

After user logout, invalidate session identification tokens by explicitly expiring and destroying the
session on server.
Validate Session Identifiers

Configure the web application framework to enforce session identifier constraints to the highest
degree possible. The application must validate the session identifiers for type, length, and special
characters to verify that they are not holding any malicious content.

Internal Use Only
Enforce Session Identifier Security
To prevent session hijacking, the application must protect session identifiers during transit. The
application must generate the session IDs using strong, non-predictable algorithms. Secondly,
session identifiers must not be stored in persistent cookies or in hidden fields. Instead, session IDs
should be stored in non-persistent cookies with the secure flag enabled. Finally, session cookies
must be configured to restrict distribution beyond the application via proper use of the domain and
path attributes in the cookie.
Enforce Session Expiration

Sessions must expire after a maximum of 30 minutes of user inactivity. Additionally, sessions should
expire after a maximum of 24 hours, regardless of activity.
Secure Coding
This section provides some coding guidelines which will help eliminate or reduce coding flaws that
can lead to security vulnerabilities.
Validate all Input

 Validate input parameters (on every data entry point within the application) for type, length,
syntax, and range, using regular expressions or otherwise.
 Validate length, reject empty fields if applicable and set and enforce a "too long" value for
every field.
 If the data should follow a known pattern (ip, phone no, etc.), validate it using a regular
expression or equivalent.
 If the data does not follow a known pattern, make sure that it does not contain undesirable
punctuation or special characters including many (but not all) between 129 and 256 ascii.
 In particular, never trust anything from the HTTP request, which includes HTML form
fields, URL parameters, HTTP cookies, and HTTP headers. User controlled files and
database queries are also potential data entry points that should be properly validated.
Proper input validation can eliminate the vast majority of software vulnerabilities such as
injection attacks.

Internal Use Only
Never Rely on Client-side Data Validation
Hackers can always bypass client-side validation. Therefore, ensure that your web application
checks every validation and business rule on the server-side, rather than on the client browser.
Client-side validation is optional, but the application should never depend on it.
Sanitize Data Passed to other Systems
When passing string data containing special characters to other systems, make sure the data is
properly sanitized so that the other system will not interpret the string as an executable command. If
not properly sanitized, the special characters can trigger commands that can lead to injection
attacks, data integrity issues, and loss of sensitive data. Data sanitization entails either eliminating
unwanted characters altogether, using a white list of safe characters, or escaping / encoding the
special characters according to the target system‘s character-set specifications.
Prevent Common Coding Vulnerabilities Identified in the OWASP Top 10 List
The OWASP Top 10 project lists the most serious web application vulnerabilities and discusses how
to prevent them. The application must not be susceptible to these vulnerabilities. Architects,
developers, and testers must mitigate these vulnerabilities by following OWASP recommendations
[6]. The Top 10 list for 2010 is as follows:
1. Cross site scripting (aka XSS)
2. Injection flaws (e.g., SQL Injection [5])
3. Insecure direct object reference
4. Cross site request forgery (aka CSRF)
5. Broken authentication and session management
6. Insecure cryptographic storage
7. Insecure communications
8. Failure to restrict URL access
9. Security misconfigurations
10. Unvalidated redirects and forwards.
Fail Securely
When an error or exception occurs during program execution, look at source code where the error
occurred and determine how the failure impacts security. Does the continuation of the application
degrade security and if so is this degradation acceptable?

Internal Use Only
Consider the following code for a scenario when the code fails insecurely:
try {
elevatePrivilege();
readSecretFile();
lowerPrivilege();
} catch (FileNotFoundException e) {
reportException(e);
}
If readSecretFile() throws an exception, the code does not lower the privileges and the application
continues to execute in elevated privilege mode. This might be unacceptable if the application is
critical. The solution is to undo the changes to the privilege level and to restore the system to a
secure state:
try {
elevatePrivilege();
readSecretFile();
} catch (FileNotFoundException e) {
reportException(e);
} finally {
lowerPrivilege();
}

Internal Use Only
Database Calls
Use PreparedStatements with “bind variables” to prevent SQL injection.
The application code must never use unchecked input values within SQL statements. Input values
must be validated for type, length, syntax, and range [5]. In addition to input validation, the
application must properly escape all characters that are acceptable to the application but are
dangerous within the context of SQL statements, such as single quotes (‗), which might be
acceptable within name fields.
To solve this problem, the application should use JDBC PreparedStatements with ―bind variables‖
(also called Parameterized PreparedStatements) as the JDBC driver automatically escapes all input
arguments to parameterized PreparedStatement calls.
It is important to note that using PreparedStatements without bind variables does not necessarily
prevent SQL injection attacks. See the OWASP write-up [5] for more details on SQL injection
prevention using parameterized vs. non-parameterized PrepareStatements.
Use Limited Privileges
Database connections should be created using limited privilege accounts. The application should not
login to the database using sa or dbadmin accounts.
Cryptography
Web applications should use the algorithm specifications listed in the following table to ensure that
strong cryptography is being used to protect confidentiality and integrity of sensitive data.
Algorithms Key size
Symmetric Algorithms AES At least 128 bits
Asymmetric Algorithms RSA At least 2048 bits
Message Digest Algorithms SHA-224, SHA-256 Not applicable
Additionally, applications must avoid frequent misuses of cryptography, including [11]:

 Poor source of random numbers for cryptographic algorithms
 Not managing key material safely
 Hiding cryptographic credentials in client software or on client systems
 Use of homegrown cryptographic algorithms
 Use of homegrown implementation of well-known cryptographic algorithms

Internal Use Only
Infrastructure and Communication Security

Secure the Web Server
NOTE: For platform-specific requirements, also refer to the ―
InfoSec – Server Hardening
Requirements‖ zip folder available on the MyPepsiCo Agency / Vendor portal – Forms, Tools, and
Reference portlet.
 Remove extraneous and default content from web servers
Remove all extraneous and default contents from production servers, such as sample
applications, manuals, default software features, and demonstration code. This information
may aid a hacker to extend or discover potential vulnerabilities.
 Disable Directory Listing
Disable Directory listing on production web servers. Directory listing can expose files that
would otherwise have been unknown to attackers.
 Disable Dangerous HTTP Methods
The HTTP PUT and HTTP DELETE methods allow file manipulation on the web server.
Using the PUT method and a writeable directory, attackers can upload content to the web
server. Depending on directory permissions, they may even be able to execute malicious
scripts. The DELETE method allows attackers to delete content from the web server, causing
a denial of service. Disable or block these methods on production web servers.
 Disable HTTP Trace
TRACE‘ is an HTTP method which echoes input back to the user and is used for debugging.
Attackers can use this method to steal sensitive information such as cookies and user login
credentials [7]. Disable HTTP TRACE on your production web servers.
 Remove Unnecessary Services from the Web Server Host
Unused services might include FTP, SNMP, NFS, BOOTP, and NEWS. FTP is especially
problematic and must be removed.

Internal Use Only
 Suppress the HTTP “Server” Response-Header
Most web servers will include a ― Server‖ header field within HTTP responses sent to clients
[9]. This field contains information about the software that the web server uses to handle
requests. An example of the Server response-header field is as follows:
Server: IBM_HTTP_Server/2.0.47.1-PK29827 Apache/2.0.47 (Unix) DAV/2
Revealing the specific software version of the server and of the underlying OS might allow
the server machine to become more vulnerable to attacks against software that is known to
contain security holes.
 Disallow Referer-based Security Checks
The referer HTTP request header field must not be used to make security decisions. It is
easily modifiable and spoofed by hackers.
 Disable Autocomplete
For HTML fields that capture sensitive data such as passwords and credit card numbers, set
the AUTOCOMPLETE attribute to OFF to prevent browsers from caching the data locally.
<form … AUTOCOMPLETE=‖OFF‖> - for all form fields
<input … AUTOCOMPLETE=‖OFF‖> - for just one field
 Disable Default Accounts
The web application must have no default accounts, i.e., accounts with well-known
usernames and passwords such as root, sa, admin, or Administrator. Ensure that the
underlying infrastructure has no default accounts left active either.
 Disallow “Remember Me” Functionality
―Remember Me‖ functions allow users to return to their personalized accounts without being
required to log back into the application. After a period of inactivity, force the user to re-login
before viewing any high value resources or engaging in any high value transactions.
 Enforce Idle Timeout
Determine a suitable idle timeout period with the business. Close the session after the
timeout expires. It is recommended that the idle timeout be set to five minutes for highly
protected applications and to no more than 30 minutes for low risk applications.

Internal Use Only
 Logout Users Securely
o Implement logout functionality.
o Include a logout button on every view and not just the index page.
o Ensure that logout abandons or closes the session and clears any cookies left on the
browser.
 Expire Accounts Securely
o Accounts that have not been logged in for a long time should be locked out or
preferably removed.
o Users should have the ability to remove their accounts using some simple
mechanism.
Secure Socket Layer
 Use either SSLv3 or TLSv1. SSL versions before 3.0 are insecure and should not be used.
 At the server, disable ―
weak‖ ciphers suites, i.e., those that use less than 128-bit key lengths
for symmetric algorithms. An example of a weak cipher suite is
―TLS_RSA_WITH_DES_CBC_SHA‖.
 Do not use any cipher suites that are not included in the SSLv3 or TLSv1 predefined set of
cipher suites because they pose potential security vulnerabilities.
 Avoid anonymous Diffie-Hellman cipher suites (i.e., that use ―
anon‖ for the certificate
exchange algorithm), such as ―TLS_DH_anon_WITH_3DES_EDE_CBC_SHA‖. Usage of
these cipher suites makes the SSL connection vulnerable to man-in-the-middle attacks.
 Avoid cipher suites with ―NULL‖ for symmetric key encryption algorithm because these suites
do not encrypt data for transmission over the network. An example of such a suite is
―TLS_RSA_WITH_NULL_SHA TLS_RSA_WITH_NULL_MD5‖.
NOTE: SSL certificates must be kept current at all times

Internal Use Only
HTTP Cookies
Cookies provide web applications with a simple mechanism for managing user sessions. Though
indispensable to application session management, the liberal use of cookies may open applications
to serious security vulnerabilities.
Some common attack scenarios to be aware of come in the following forms: cookies can be read
and modified on the client machine by malicious users or software (i.e., Trojans); cookies can be
intercepted while in transit over the network, or can be stolen from the browser through XSS attacks,
even distributed by the browser to unintended applications, saved on the client machine‘s hard
drive for long durations unnecessarily, and inadvertently sent over plain HTTP, when HTTPS
was required.
Solutions to these attack scenarios include:
 Encrypt sensitive data values: The application should always be suspicious of data coming
from browser clients, whether it is in HTTP forms or cookies, as it is easy to tamper with any
of these data placeholders while they reside on the client machine. This applies even when
the application is using HTTPS, as HTTPS can only protect the channel, rather than the two
endpoints of the channel. For instance, if a hacker manages to install a Trojan on the client
machine which is able to read the browser‘s address space for sensitive client-side data, any
such data is thus compromised. Therefore, all sensitive data that is going to be sent to the
browser must be encrypted. This includes not just cookies but also form fields.
 Use cookies only for JSESSIONIDs: Do not use cookies for transmitting authentication
information such as usernames and passwords; cookies were not designed for this purpose
[3]. Use cookies instead to pass tokens like session identifiers, e.g., JSESSIONID in J2EE
environments, which the application will then match to the user‘s data stored on the server
within the session object.

Internal Use Only
 Configure cookie attributes for strong security: If it is unavoidable to use cookies for
transmitting sensitive data, ensure that the following cookie attributes are properly configured
to reduce the risks associated with passing around sensitive data inside cookies:
o Ensure that cookies are always sent over HTTPS, rather than plain HTTP. You can
do this by enabling the secure attribute on the cookie.
o Ensure that the cookies are created as ― non-persistent‖ [4], i.e., they are destroyed
when the browser is closed, and are thus never stored on the client‘s hard drive. To
create ― non-persistent‖ cookies, simply leave out the expires attribute in the Set-
Cookie command.
o Use the domain and path attributes to define the exact URLs to which browsers will
submit your cookie. Make the two attributes as restrictive as possible.
o Use the httpOnly attribute to prevent cross-site scripting attacks from stealing the
cookies. This attribute prevents Javascript from accessing the cookies. Currently,
only the latest versions of Internet Explorer and Firefox support this attribute.
 Validate cookie data: Before using any cookie data, examine cookie content to verify that
they are not storing malicious content by performing proper input validation for type, length,
syntax, and range.

Internal Use Only
Patching
As patching technology evolves and attackers develop new methods to exploit vulnerabilities, the
management of computer security becomes increasingly critical in maintaining the integrity of the
business infrastructure. As a proactive initiative, security patch management is the primary line of
defense for protecting a corporate computing infrastructure.
Security patch management is patch management with a focus on reducing security vulnerabilities.
Security patch management as a functioning procedure ensures that all identified software updates
are in place, thereby eliminating vulnerabilities from the environment and mitigating the risk of
computers being compromised.
Ensure successful testing of a security patch by first taking the following steps.
Understand the files, functions and operations of the security patch
To ensure that all groups (e.g., server, application or desktop groups) comprehend the full impact of
its installation, the following questions should be answered by the individuals (e.g., security team
members or tool administrators) responsible for patch management:
 What problem does this patch solve?
 What systems are affected?
 What files are affected?
 Does the target system require a reboot?
 Does the target software process require a restart?
 Does the patch have an uninstall feature?
 If the patch or uninstall fails, how can the system be recovered?

Internal Use Only
Prioritize and rate the severity of each security patch.
The following table shows an example of how to prioritize patches based on criteria, along with the
recommended and maximum timeframes associated with each. This table helps set the priority of a
patch when it is released.
Maximum
Priority Recommended Recommended
Priority Color Criteria Timeframe Timeframe
Organization is vulnerable,
an exploit has been Deployment must
1--Emergency Red published and other start within five Within ten days
organizations are being days.
affected by the exploit.
Deployment must
Organization is vulnerable, Deployment must
start within three
2--Critical Orange but no known exploitation of conclude within four
weeks of patch
the vulnerability. weeks of patch release.
release.
Rating Criteria of Patches

Internal Use Only
Initiate the change control procedure within the organization.
The change control procedure or process is a set of documented steps that all changes must go
through prior to installation on any systems or devices.
Change management ensures that modifications to systems occur in a controlled environment.

While initiating change control is possible after releasing a patch, it is important to complete change
control prior to testing the patch and preparing it for deployment.
Change control is executed according to the priority level of the patch. For example, if a patch is
categorized as "Emergency" or "Red," an expedited version of the change control procedure is
implemented to ensure the patch is installed within the required timeframe.
Security patch testing and deployment phase:
A security-related patch can affect many different parts of a system depending on the issue is it is
supposed to fix and what is contained within the patch to do so. Therefore, testing must be included
in the patching procedure and conducted for each patch planned for deployment.
The goal of testing is to ensure that when a patch is deployed, the system's operations and
applications are not impacted and business is not interrupted. To achieve this goal, the following
minimum conditions must be met, and their success documented, before proceeding to the
deployment phase:
 The testing environment simulates a majority of the targeted platforms
 The software delivery process succeeds on the targeted test platform
 The patch is installed on the target platform without significant issues
 Previously functioning operations on the target platform continue to operate after installation
of the patch
 The patch is successfully removed in case of problems
If any of these conditions is not met, additional testing is performed prior to deploying the patch onto
a vulnerable system. A few iterations may be required to ensure successful deployment and to
reduce the risk of negatively impacting the affected system.

Internal Use Only
Once the security patch successfully passes through the testing phase, you can begin the
physical deployment process. Patches must be deployed in a manner that guarantees repeatability,
consistency, status tracking, and error logging. This is typically achieved with a patch
management tool.
Verify patch implementation
The intricacies of software installation compel the separation of the deployment and verification
procedures. During deployment, success or failure is judged based on feedback from the security
patch management tool.
The verification process involves checking the related files, binary versions, and registry settings to
confirm the patch has taken effect.
Patch verification must use methods that check for the specific characteristics of the patch. The
verification process is primarily conducted by the tool, unless the tool is not capable of doing so,
then it must be done manually.
Review patch status
The change control procedure -- be it a tool, ticket or form -- should be updated as each step is
completed. Also, a report should be generated to record the status of each patch. As part of the
report, the patch management team should receive the following information:
 Number of systems successfully patched
 Number of systems that failed patching or were unsuccessfully patched
 Summary indicating why the failures occurred and the follow-up steps
 Reboot request reporting
 Number of systems that were omitted from the process, which is typically provided within the
accompanying exception report
 Summary indicating why these systems were omitted from the process
 Reporting effectiveness

Internal Use Only
Application Testing
Application testing is a method of evaluating the security of an application by simulating an attack
as that of a malicious hacker. The process involves an active analysis of the system for any
weaknesses, technical flaws or vulnerabilities.
Applications must be tested and evaluated to validate that the developed system complies with the
functional and security requirements. Testing of security controls is based on technical security
specifications. The testing must be scoped to test the relevant security requirement as it is intended
for use in its environment. For repeatability, the testing process must be capable of the execution of
a series of tests against an information system more than once (or against similar systems in
parallel) and yield similar results each time. For iteration, each system will be required to execute
functional tests in whole or in part a number of successive times in order to achieve an acceptable
level of compliance with the requirements of the system. To achieve this, functional testing will be
automated to the degree possible, and the test cases will be published, in detail, to ensure that the
test process is repeatable and iterative.
Only test or ―stub‖ data should be used during system development. Absolutely no operational,
security-relevant, or personally identifiable information (PII) should reside within any system or
software during development.
Source Code Review
It is the process of checking a web application's source code for security issues. Many serious
security vulnerabilities cannot be detected with any other form of analysis or testing including
penetration testing. With availability of source code, a tester can accurately determine what is
happening (or is supposed to be happening) and remove the guess work of black box testing.
This testing must be performed during code development and prior to promoting the code into
production environment.
Penetration Testing
Penetration testing is also commonly known as black box testing or ethical hacking. Penetration
testing is essentially the ―
art‖ of testing a running application remotely, without knowing the inner
workings of the application itself, to find security vulnerabilities. Typically, the penetration test team
would have access to an application as if they were users. The tester acts like an attacker and
attempts to find and exploit vulnerabilities. In many cases the tester will be given a valid account on
the system.

Internal Use Only
While penetration testing has proven to be effective in network security, the technique does not
naturally translate to applications. When penetration testing is performed on networks and operating
systems, the majority of the work is involved in finding and then exploiting known vulnerabilities in
specific technologies. As web applications are almost exclusively bespoke, penetration testing in the
web application arena is more akin to pure research. Penetration testing tools have been developed
that automate the process but again, with the nature of web applications, their effectiveness is
usually poor. Many people today use web application penetration testing as their primary security
testing technique. While it certainly has its place in a testing program, we do not believe it should be
considered as the primary or only testing technique. Gary McGraw in [14] summed up penetration
testing well when he said, ― If you fail a penetration test you know you have a very bad problem
indeed. If you pass a penetration test you do not know that you don‘t have a very bad problem‖.
However, focused penetration testing (i.e., testing that attempts to exploit known vulnerabilities
detected in previous reviews) can be useful in detecting if some specific vulnerabilities are actually
fixed in the source code deployed on the web site.
Approach and Methodology
Approach and Methodology
Initiate Scan Vulnerability Vulnerability Evidence Reporting
Identification Exploitation Collection
1 2 3 4 5
Steps Steps Steps Steps Steps

 Define Objectives  Port Scanning  Gain privileged  Collect evidence  Halt penetration
 Define Scope  Scan vulnerabilities access to  Rollback the activities
 Gather Information on application resources targets to original  Data analysis and
about target  Assess OWASP  Simulate attacks configuration conclusions
 Identify OS, Web vulnerabilities  Password state  Preparation of
Servers, Appservers  Classification & cracking Report document
 Application Profiling Characterization of
Vulnerabilities
Deliverables
 Objectives and Scope statement
 Summary report of the engagement
 Detailed Report:
- Vulnerability Assessment
- Activity report detailing steps to gain privilege
- Reporting evidence of test
- Recommending counter measures to fortify security posture

Internal Use Only
Operations Operational Procedures

 Development, test, and operational facilities should be separated to reduce the risks of
operations unauthorized access or changes to the operational systems.
 Development, test, and operational facilities should be separated to reduce the risks of
unauthorized access or changes to the operational systems.
 The Application team shall make software changes in the development environment and
promote them to the staging environment, when appropriate.
 Conduct monthly system vulnerability assessments and risk reviews.

Internal Use Only
Appendices Appendix A: Third party service delivery management

Third party security review is required for access or to process any restricted or privileged electronic
appendices information, (sales and pricing, financial, formulary, trade secrets, strategic plans, HR, medical, etc.),
whether those functions occur on PepsiCo systems or on systems under the vendor‘s direct or
indirect control.
The Request for Third Party Security Review form is found at this link:
https://www.mypepsico.com/ep/common/security/portfolio/third-party/thirdparty-review.htm
Do NOT provide external parties access to the organization‘s information until the appropriate
controls are implemented as required in the third party security assessment.
Appendix B: Information exchange policies and

procedures
Disable the use of unsecured protocols for storing and transmitting PepsiCo Restricted and Internal
Use Only data. See Data Classification Policy in PepsiCo Information Security Policies.
Implement only PepsiCo approved encrypted standard for securing data-at-rest and in-motion.
Currently approved encryption and hashed algorithms are:
 MD5
 SHA-1 with 128-bit or 160 bit key
 Blowfish
 Triple-DES
 Pretty Good Privacy (PGP)
 Secure Socket Layer (SSL)
 Advanced Encryption Standard (AES)

Internal Use Only
Appendix C: References
[1] OWASP Guide to Building Secure Web Applications and Web Services
(http://www.owasp.org/index.php/OWASP_Guide_Project)
[2] RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication
(http://www.ietf.org/rfc/rfc2617.txt)
[3] RFC 2965 - HTTP State Management Mechanism
(http://www.faqs.org/rfcs/rfc2965.html)
[4] Mitigating Cross-site Scripting With HTTP-only Cookies
(http://msdn2.microsoft.com/en-us/library/ms533046.aspx)
[5] Preventing SQL Injection in Java
(http://www.owasp.org/index.php/Preventing_SQL_Injection_in_Java)
[6] OWASP Top 10 2010 (http://www.owasp.org/index.php/OWASP_Top_Ten_Project)
[7] What is HTTP TRACE? (http://www.cgisecurity.com/questions/httptrace.shtml)
[8] Understanding Malicious Content Mitigation for Web Developers
(http://www.cert.org/tech_tips/malicious_code_mitigation.html)
[9] Hypertext Transfer Protocol – HTTP/1.1
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.38)
[10] US-DHS Build Security In – Design Principles - Fail Securely
(https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles/349.html)
[11] US-DHS Build Security In – Guidelines – Use Well-known Cryptography Appropriately and
Correctly (https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/guidelines/334.html)
Appendix D: Recommended reading

[1] The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About
Unicode and Character Sets (No Excuses!)
(http://www.joelonsoftware.com/articles/Unicode.html)
[2] Mask Your Web Server for Enhanced Security by Joe Lima & Thomas Powell
(http://www.evolt.org/node/60160)
[3] NIST Guidelines on Securing Public Web Servers – Special Publication 800-44, Version 2.

Internal Use Only
<TITLE PLACEHOLDER>
PepsiCo
STANDARD

social media security
Description ................................................................... 7.11.4

contents Issues........................................................................................................................ 7.11.4
Facebook secure development ..................................... 7.11.6

How does Facebook work – the front end ................................................................. 7.11.6
How does Facebook work – the back end ................................................................ 7.11.7
Integration into the Facebook platform ...................................................................... 7.11.9
Security guidelines...................................................... 7.11.11

PepsiCo secure development guideline – general .................................................. 7.11.11
PHP vulnerabilities..................................................... 7.11.13

Documented PHP vulnerabilities ............................................................................. 7.11.13
Securing against PHP vulnerabilities ...................................................................... 7.11.14
Documented iFrames vulnerabilities ....................................................................... 7.11.16
Securing against iFrames vulnerabilities ................................................................. 7.11.19
Cross domain police ................................................... 7.11.31

HTTPS protocol .......................................................... 7.11.33
Secure transport using SSL .................................................................................... 7.11.33
Ensure sensitive API calls use HTTPS endpoints ................................................... 7.11.33
Ensure sessions with the secure site are initiated over HTTPS .............................. 7.11.34
Set the secure flag on all sensitive cookies ............................................................. 7.11.34

Internal Use Only
Administrative ............................................................. 7.11.35

Administrative functionality ...................................................................................... 7.11.35
Require HTTPS ....................................................................................................... 7.11.35
Host administrative functionality on a different domain ........................................... 7.11.36
Make endpoints available internally only ................................................................. 7.11.36
Require additional authentication ............................................................................ 7.11.36
References ................................................................ 7.11.37

Internal Use Only
Description Social networking is the art of connecting with those who share
common interests. This includes several networking sites including
description but not limited to Facebook, LinkedIn, MySpace and Flickr. These
networks are a community that helps keep you united with others
and offers many benefits. For example, people have been
“facebooking” each other for about six years now, making Facebook
the most used social network with over 350 million users worldwide.
Networking via social media sites has revolutionized how we use the
Internet and is at the forefront of next level of evolution of the Web.
Issues
Social networking sites have received fair amount of review and scrutiny because of well-
known exploits as well as security issues inherent in the technologies utilized by these
providers.
In a recent post on the Social Media Security blog, ethical hacker James F. Ruffer III of
Unibox explained how with access, a hacker can control every aspect of the victim’s
Facebook profile, including the victim’s Facebook pages. He added, “Once I am in, the
victim has to check secure browsing, log out, and log back in,” he says. “That’s the only way
to destroy my attack vector.” Firesheep is a Mozilla Firefox browser extension and utilizes
packet sniffing methods to intercept unencrypted cookies or sessions.

Internal Use Only
Techniques such as “sidejacking” or by utilizing a Mozilla Firefox plugin called Blacksheep,a
hacker can very easily create a mirror of a victim’s account even control the profile.
In “sidejacking,” although the hacker doesn’t have control over the victim’s account, they
have mirrored what the victim is doing from his or her browser onto theirs. Due to the high
level of attention this security flaw demanded, a Mozilla Firefox plugin called Blacksheep
was quickly developed to detect if Firesheep is being used on a network, Blacksheep tries
to create “false” sessions IDs on a network to see if the sessions are being hijacked.
Hackers can also use Firesheep to extend their access to Social Media Management
platforms and still get simultaneous control of all the victim’s profiles from there, even if the
https secure browsing is enabled.

Internal Use Only
Facebook Before we can begin to secure development and applications in

Facebook
secure Facebook, we have to first understand how Facebook works. Let us
secure
development
review Facebook’s inner workings, covering its architecture and
frontend/backend infrastructure, the nuts and bolts that hold
development Facebook together.
How does Facebook work – the front end

Facebook uses a variety of services, tools, and programming languages to make up its core
infrastructure. At the front end, their servers run a LAMP (Linux, Apache, MySQL, and PHP)
stack with Memcache.
Linux & Apache

Facebook runs the Linux operating system on Apache HTTP Servers.
MySQL
For the database, Facebook utilizes MySQL because of its speed and reliability. MySQL is
used primarily as a key-value store as data is randomly distributed amongst a large set of
logical instances. These logical instances are spread out across physical nodes and load
balancing is done at the physical node level.
As far as customizations are concerned, Facebook has developed a custom partitioning

scheme in which a global ID is assigned to all data. They also have a custom archiving
scheme that is based on how frequent and recent data is on a per-user basis. Most data is
distributed randomly.

Internal Use Only
PHP
Facebook uses PHP because it is a good web programming language with extensive
support and an active developer community and it is good for rapid iteration. PHP is a
dynamically typed/interpreted scripting language.
Memcache – Memcache is a memory caching system that is used to speed up dynamic

database-driven websites (like Facebook) by caching data and objects in RAM to reduce
reading time. Memcache is Facebook’s primary form of caching and helps alleviate the
database load.
Having a caching system allows Facebook to be as fast as it is at recalling your data. If it

doesn’t have to go to the database it will just fetch your data from the cache based on your
user ID.
How does Facebook work – the back end

Facebook’s backend services are written in a variety of different programming languages
including C++, Java, Python, and Erlang. Their philosophy for the creation of services is as
follows:
1. Create a service if needed
2. Create a framework/toolset for easier creation of services
3. Use the right programming language for the task
A list of Facebook’s open source developments and a few of the essential tools that
Facebook has developed are included here.

Internal Use Only
Thrift (protocol)
Thrift is a lightweight remote procedure call framework for scalable cross-language services
development. Thrift supports C++, PHP, Python, Perl, Java, Ruby, Erlang, and others. It’s
quick, saves development time, and provides a division of labor of work on high-
performance servers and applications.
Scribe (log server)

Scribe is a server for aggregating log data streamed in real-time from many other servers. It
is a scalable framework useful for logging a wide array of data. It is built on top of Thrift.
Cassandra (database)
Cassandra is a database management system designed to handle large amounts of data
spread out across many servers. It powers Facebook’s Inbox Search feature and provides a
structured key-value store with eventual consistency.
HipHop for PHP

HipHop for PHP is a source code transformer for PHP script code and was created to save
server resources. HipHop transforms PHP source code into optimized C++. After doing this,
it uses g++ to compile it to machine code.

Internal Use Only
Integration into the Facebook platform

The Facebook application developer has many choices in how they integrate into the
Facebook platform with their application. In general, there are two main categories of
Facebook applications: Platform applications and Facebook Connect applications. Both
types of application can use Facebook markup and scripting languages, as well as a REST
client to access the Facebook API. Facebook Connect applications communicate with
Facebook through cross-domain communication channels. Platform applications
communicate directly with the Facebook servers. The following terms will be referenced
when discussing Facebook applications:
Application Canvas
The application canvas is the page on Facebook servers where an application lives.
Application canvas pages are accessed through the apps.facebook.com domain. For
example, the application canvas URL for a fictional game called “Goatworld” might look like
this: http://apps.facebook.com/goatworldgame/. The application canvas page will either be
Facebook markup language or an external site hosted within an IFRAME.
Canvas callback URL

The canvas callback URL is the file or directory on the developer’s application servers
where the application files are hosted. Facebook proxies the content from the canvas
callback URL to the application canvas page.

Internal Use Only
Post-Authorize callback URL
The callback URL is a page on the developer’s servers which is pinged by Facebook each
time a user authorizes the application. Platform applications Platform applications run in a
sandbox and are accessed through the application canvas page. There are two types of
platform applications that use different methods for sandboxing, including FBML and
iFRAME.
FBML
Applications written using the Facebook markup and scripting languages instead of the
traditional HTML and JavaScript. When a user accesses the application canvas page, the
Facebook proxy pulls down the FBML from the application servers and translates it into
HTML before rendering in the user’s browser. It follows that the application code runs in the
apps.facebook.com domain. These applications can access Facebook user data directly
using FBML, but may also make calls to the Facebook REST API servers.
iFRAME
Applications that are written using traditional web development languages such as HTML,
JavaScript, CSS, and run on the developer’s application servers in an IFRAME hosted in the
Facebook application canvas page. These applications cannot use FBML directly, so they
tend to rely on components from Facebook Connect, such as XFBML and the JavaScript
client library, as well as the Facebook REST API.
Facebook Connect applications

Facebook Connect applications do not run directly on the Facebook platform, but can
access a set of powerful APIs to integrate closely with Facebook. Facebook Connect
applications can be web, mobile or desktop applications. Connect applications use XFBML
tags (which are similar to FBML) as well as the JavaScript client library, the Facebook PHP
client or a Facebook REST client in any language.

Internal Use Only
Security The first step in securing any application is to outline the required
security
guidelines security guarantees your application needs to make, and then to
guidelines select mechanisms that support those guarantees. For a Facebook
application, the security challenges are slightly different than a
regular application. The following is a non-exhaustive list of important
items that a Facebook application developer has to keep in mind
when thinking about security.
PepsiCo secure development guideline – general

1. All development must follow PepsiCo “Web Application Security Best Practices”
guide. Reference this guide for the following:
Access Controls
Authentication
 Secure Handling Of Credentials
 Handling Of Sensitive Data Over Post
 Use of Fail-Safe Login Mechanisms
 Streaming of Data to Internal Clients
Authorization
Use of Client-Side Tokens
Session Management
Cryptography
Infrastructure and Communications Security

Internal Use Only
2. All application code shall be developed using OWASP Secure Coding Practices.
3. Application Testing shall be performed as follows:

 Static vulnerability analysis shall be performed in code testing phase as well
as after code has moved to production.
 Testing shall use a reputable tool (e.g. Whitehat) that has been approved by
PepsiCo to scan the application.
 Application code analysis shall use a reputable tool (e.g. Fortify) that has been
approved by PepsiCo to scan the code.
 Environment analysis shall use a reputable tool (e.g. Qualys) that has been
approved by PepsiCo to scan.
 Identified vulnerabilities shall be remediated prior to moving the code to
production.
4. Integration of PepsiCo (e.g. content/functionality) to third party sites (e.g. Facebook,
Brand Partner site)
 Developers shall comply with the OWASP for secure Facebook development.
(https://www.owasp.org/index.php/Facebook)
 PepsiCo site shall be configured to use the Secure Canvas and Tab
5. Third Party Partner Integration
 iFrame calls a secure URL.
 Environment and application level scans shall be conducted on third party
environment
6. Data – Dependent the business requirement and PepsiCo approval
 Transmission - data shall be encrypted in motion (i.e. https via Secure Socket
Layer (SSL)).
 Database – data must be encrypted

Internal Use Only
PHP Documented PHP vulnerabilities

PHP
vulnerabilitie Several vulnerabilities and weaknesses have been reported in PHP. Several of these can
be exploited by malicious users to manipulate certain data, disclose potentially sensitive
svulnerabilities information, bypass security restrictions, or to cause a DoS (Denial of Service), and
potentially by malicious people to compromise a vulnerable system. Some reported
vulnerabilities include the following:
1. An input validation error in the "ftp_putcmd()" function can be exploited to inject

newline characters.
2. An unspecified error in the "import_request_variables()" can be exploited to
overwrite global variables.
3. An unspecified error can remotely be exploited to cause a buffer overflow within in
the "make_http_soap_request()" function (PHP 5)
4. An unspecified error can be exploited to cause a buffer overflow within the
"user_filter_factory_create()" function (PHP 5).
5. An unspecified error in the bundled libxmlrpc library can remotely be exploited to
cause a heap-based buffer overflow and may allow execution of arbitrary code.
6. An input validation error in the "mail()" function allows injection of headers via the
"To" and "Subject" parameters.
7. An error in the "mail()" function allows to truncate messages via ASCIIZ bytes.
8. The "safe_mode" and "open_basedir" protection mechanisms can be bypassed via
the "zip://" and "bzip://" wrappers.

Internal Use Only
9. An integer overflow exists in "substr_compare()", which can be exploited to read
memory from memory behind PHP variables. The "substr_count" function is
reportedly also affected.
10. An error in the "mb_parse_str()" can be exploited to activate "register_globals".
11. An error in the Zend engine related to nested array variables that can be exploited to
crash a PHP application.
12. A weakness is caused due to the use of an uninitialized variable when calling
"php_rand_r()" within the "mcrypt_create_iv()" function of the mcrypt module if
MCRYPT_RAND is passed as a parameter, which may result in a weaker encryption
(PHP 5).
Securing against PHP vulnerabilities

API abuse
Functions that cannot be used safely should never be used. Certain functions behave in
dangerous ways regardless of how they are used. Functions in this category were often
implemented without taking security concerns into account.

Internal Use Only
Encapsulation – system information leak
Revealing system data or debugging information helps to establish “foot print” of the system
and form a plan of attack.
An information leak occurs when system data or debugging information leaves the program
through an output stream or logging function.
Example: The following code prints an exception to the standard error stream:
<?php
echo "Server error! Printing the backtrace";
debug_print_backtrace();
?>
This information can be dumped to a console, written to a log file, or exposed to a remote
user. In some cases the error message tells the attacker precisely what sort of an attack the
system is vulnerable to. For example, a database error message can reveal that the
application is vulnerable to a SQL injection attack. Other error messages can reveal more
oblique clues about the system. For example, it could include information about the type of
operating system, the applications installed on the system, and the amount of care that the
administrators have put into configuring the program. This leads to excessive information
and provide clear path of exploitation and unauthorized activity.

Internal Use Only
iFrames vulnerabilities
Documented iFrames vulnerabilities
iFrames Browser cross domain exploits
vulnerabilities Since another website page can be embedded a page; this can then be used to exploit that
page and perform actions as that user and doing anything on a chosen web site.
XSS/CSRF reflection attacks

Using iFrames embedded onto a compromised site an attacker then can reflect attacks to
other servers therefore making attacks difficult to trace and having a focal point to conduct
attacks.
A common example of this vulnerability is a web page which takes values from request
parameters and includes them directly in HTML or JavaScript without validation or
sanitization. Consider an example PHP page from an application which displays a
username passed in via GET request parameters. The source of this page contains the
following code:
< ?php
echo(“Your username is:”.$_GET[“username”]);
?>
Now imagine that a malicious user tampers with the request parameters and enters the
following string in the username field:
< script>alert(document.cookie);< /script>

Internal Use Only
The source of the resulting page will then contain:
Your username is:
< script>alert(document.cookie);< /script>
When the browser renders this page, the script tag that was entered as the username will
be written to the source of the page. The browser will parse it as HTML and the script will be
executed. The malicious user can then exploit this vulnerability against other users by
creating a request such as the following:
http://example.com/displayUserName.php?username=< script>alert(document.cookie);<
/script>
The attacker must then convince their victims to load the malicious request in a browser with
an active session on the vulnerable site. The attacker may do this by disguising the link with
a tiny URL service and putting it in a place logged in users are likely to visit, such as a
forum, or by posting it on a Facebook page. When victims load the malicious request in their
browser, the attacker injected script will execute and the user’s session cookie will be
revealed to the attacker (in a real world scenario the script would contain something much
more malicious than an alert box). For example, the SAMY MySpace worm was propagated
by exploiting an XSS vulnerability2. The attacker could also use an XSS vulnerability to
rewrite the source of the page so that it becomes a convincing phishing page, or a page
which prompts users to install malware. Even cautious users may be tricked, as the page
originates from a domain which they trust. This attack can be used in many different ways to
compromise the user’s browser and session, and is also usually very easy to exploit

Internal Use Only
In order to protect against this vulnerability, the developer should validate and sanitize the
value before writing it to the source of the page. The corrected code would look as follows:
< ?php
if(ctype_alnum($username)) ($_GET[“username”])){
$username = htmlentities($username);
echo(“Your username is:”.$username);
} else {
echo(“The username you entered contains invalid characters”);
}
?>
The conditional statement use the built in PHP function ctype_alnum to verify that the string
entered contains only alphanumeric characters. The htmlentities function is a built in PHP
function which output encodes un-trusted data so that it is safe to use in the HTML context,
so “<” becomes “<” and “>” becomes “>”. The user controlled data from the GET request is
now safe to write to the source of the page.
CSS and iFrames can scan your LAN from the internet
By exploiting features in CSS and using iFrames to check if the default IP address exists,
it’s possible to get your network address range quite easily providing the network device
uses the default out of the box IP address.
LAN scanning with Javascript and iFrames

Using a similar method as above it is possible to gain your LAN information using
Javascript.

Internal Use Only
CSS iFrame overlays
iFrames can be embedded inside each other in Firefox and you can alter their appearance
to create seamless overlays with any site. This would make it very difficult for a user to know
which site they are interacting with and fool them to performing an action.
URL redirection
iFrames also allow to perform redirection so you can have access to URLs which normally
wouldn’t be accessible.
Securing against iFrames vulnerabilities

Authentication and Authorization
In order for any Facebook application to make use of the API, the user must first authorize
the application and establish a session. After a user authorizes the application, a session is
created by Facebook. The session information is then passed by Facebook to the post-
authorize URL as request parameters, or it is set in cookies scoped to the application
domain using JavaScript. Facebook Connect applications rely only on cross-domain
communication between Facebook and the application to process API calls. Both Facebook
servers and the application servers must authenticate these communications. Otherwise,
attackers could spoof or tamper with requests from either party.
The API key

The API key is given to you when you setup your Facebook application. Facebook uses this
unique key to identify your application. The key is public, and will be sent in the clear with
requests sent by Facebook to your application, and can be included in client side code such
as JavaScript and Flash. NOTE: The session secret should always be used instead of the
application secret in any client side code like JavaScript, Flash, mobile or desktop
applications.

Internal Use Only
The application secret
The application secret is also distributed during application setup. This secret is used to
authenticate the communication between Facebook and your application. The secret is
private to your application and must never be revealed.
The session key

The session key is the key to a temporary session which expires after an hour or when the
user logs out of Facebook. The session key is set by Facebook when a user authorizes the
application. The session key is used to call API methods that require an active session. For
example, and calls to friends require a session key to determine which user to retrieve the
friends for.
The session secret

The session secret is a user-specific secret that can be used in place of the application
secret when generating a signature for making sensitive API calls. The session secret is
unique per user and short lived, and is thus much less sensitive than the application secret.
The session secret should always be used instead of the application secret in any client
side code like JavaScript, Flash, mobile or desktop applications. This keeps the application
secret from being revealed either directly or through reverse engineering of client side
binaries. The list of APIs which can be called using the session secret can be found here:
http://wiki.developers.facebook.com/index.php/Session_Secret_and_API_Methods

Internal Use Only
Authenticate any information received from Facebook
Authenticating information will ensure it was legitimately sent by Facebook and not spoofed
or tampered with. When Facebook passes information about the user and session to your
application in the Facebook request parameters or cookies, it may be tempting to use that
information directly from the request. However, attackers can control this data to forge or
tamper with all of the Facebook parameters sent in the request, excluding the signature.
The signature cannot be forged, as it is generated with the application secret key which the
attacker should not know. Before using the values of any of the parameters received from
Facebook, re-calculate the expected signature and verify that it matches the signature sent
with the request. In the event of a mismatch, reject the request entirely. Some of the
functions in the PHP client do this automatically. For example, the function
get_valid_fb_params from the Facebook PHP library will return the validated parameters.
Signature verification
Signature verification using the application secret must never be done on the client side, as
this would expose the secret. Always perform signature verification using server code. The
signature verification process is different depending on the type of Facebook application.
Platform applications
In platform applications, Facebook will send the signature and other parameters as part of
the GET or POST request. The application should grab the Facebook parameters from the
request parameters, and recalculate the expected signature value using the signature
generation algorithm, or the built in function from the Facebook client in use.

Internal Use Only
Facebook Connect applications
For Facebook Connect applications the Facebook parameters are sent as cookies. To verify
these parameters, the application must extract the values from the cookies and perform the
verification using the signature algorithm. The Facebook PHP client supports cookie based
signature verification and is well-tested. The verification method must be checked in any
unofficial libraries you may decide to use. Facebook Connect applications do not need to
verify the signature very often. The most common scenario which requires verification of the
Facebook cookies is when the session is being transferred from the client side to use server
side libraries. When this occurs, the application must verify the cookies sent with the
session transfer request. Otherwise, a malicious user could tamper with their cookies in
order to trick the server into believing they were another user.
Signature generation
Signatures must be generated in order to call sensitive APIs and in order to re-calculate the
signature as part of the verification process. The Facebook PHP library includes functions
for performing signature generation. For server side code, the application should generate
the signature using these API functions or by re-implementing the signature generation
algorithm. For client side code such as Flash, JavaScript, mobile and desktop applications,
which cannot use the application secret directly, there is an alternate secret used to
generate the signature: the session secret. The session secret can be used to call many
APIs, but there are some API functions that can only be called with the application secret. In
this case, the client side application should create a simple, server-hosted proxy which
makes the necessary API calls and relays the result back to the client side application.
Depending on the type of application, there are several different options for retrieving the
session secret.

Internal Use Only
Desktop and iPhone applications
Desktop and iPhone applications should either use a Session proxy to create a session and
retrieve the session secret, or embed a Web browser in the application in order to use
Facebook Connect to start the session. In order to obtain the user session in the traditional
manner, an iPhone or Desktop application would have to call auth.getSession. However,
calls to auth.getSession must be signed with the application secret. The application secret
must never be hardcoded in the source of an iPhone application. Attackers can easily
decompile Objective C and thus the secret can be discovered by anyone who downloads
the application. Therefore, this API method is not safe for direct use in iPhone applications.
The same is true for Desktop applications using Adobe Air or .NET.
The session proxy is simply a callback to an application server which then makes the
auth.getSession call on the server and returns the resulting session variables back to the
iPhone application. Ensure that the call to auth.getSession is made at an HTTPS endpoint,
as this is required to protect the session secret from being revealed to network attackers
when it is sent back to the application.
The other option is use the Facebook Connect API via a Web browser embedded in the
application. In this case, the application developer must direct the embedded browser to
Facebook login pages with specific URL parameters which direct Facebook to return the
session information. One of these parameters contains the URL to which the user will be
redirected after they successfully login. The session secret can then be retrieved from this
URL and passed back to the application. The session secret can then be safely stored on
the user’s system until they close the application.

Internal Use Only
Facebook Connect websites
When making API calls using the JavaScript client library, Facebook Connect web
applications should generate the signature for API calls using the session secret, in much
the same way that desktop applications do. The session secret will be passed to the
application callback URL after the user has authorized the application.
Flash
Flash applications will be passed the Facebook parameters as flashvars from their hosting
page. The hosting page must validate the signature on the server side before passing it to
the SWF object, as the application secret cannot be safely stored in the SWF. This is due to
the fact that SWFs can be downloaded by an attacker and easily decompiled in order to
retrieve any secrets used in the ActionScript. The ActionScript API can then use the session
secret passed in these variables to generate signatures for further API calls.
Cross Site Request Forgery (CSRF)

CSRF vulnerabilities exist when an application sends predictably structured requests which
update server side state. When such a request contains no unpredictable parameters, an
attacker can create a forged version of the request and send it on behalf of arbitrary users,
without their knowledge.
One common example of a CSRF vulnerability and protection mechanism that is used is the
password update feature of many web applications. It is a common requirement that the
user enter their current password as well as their new password in a password update form.
This requirement is in fact a CSRF protection mechanism (as well as adherence to other
design principles).

Internal Use Only
To provide protection against request forgery, the application should include and require a
CSRF prevention token in the request that is both unpredictable and uniquely tied to the
user session and action. This token will be sent with every request which updates server
side state. When the server receives a request, it can check for the appropriate token value.
If the token is incorrect or does not exist, the request will fail. One way such a token can be
generated is through: HMAC_sha1(action_name + secret, session_id) algorithm. This token
can be sent in a hidden form field with each request. The server can then perform the
calculation upon receiving the request and verify that the token sent with the request
matches. Because the secret exists only on the server side, the attacker will have no way of
formulating the token for use in a forged request. This is the recommended protection
mechanism for CSRF attacks.
In some cases the Facebook signatures can provide protection from CSRF attacks, but they
cannot be relied upon in all circumstances.
The use of the HMAC_sha1 hashing algorithm is significantly stronger than the MD5
hashing algorithm used by Facebook, which has been proven to be vulnerable to some
attacks.

Internal Use Only
Facebook signatures cannot protect against CSRF attacks when sent as cookie values.
CSRF protection tokens provide no protection when sent as cookie values. (See
http://www.win.tue.nl/hashclash/rogue-ca/) because the browser will automatically send
cookie values with the request, thus the attacker does not need to guess the value, and the
structure of the request remains predictable. Facebook Connect applications send the
signatures as cookie values, rather than request parameters. Therefore, it is important to
remember that these applications will have to provide a separate CSRF protection
mechanism. This caveat highlights one of the reasons to implement a separate CSRF
protection system that is designed specifically for this class of vulnerabilities. This way, code
can be ported to different types of Facebook (and non-Facebook) applications and will still
be protected from this class of attack.
The Facebook signature is not sent with all requests. The Facebook signature is not always
available for use as a CSRF protection token.

Internal Use Only
Cross Site Scripting (XSS)
XSS attacks are one of the most common and dangerous web application vulnerabilities. An
XSS vulnerability exists when user controlled data is written directly to the page source
without sufficient input validation or output encoding applied.
Prevent XSS attacks by using a combination of input validation and output encoding. Most
class libraries include functions for performing output encoding. While output encoding
provides strong protection against XSS, it is best to perform data validation before
encoding. The validation and encoding should always be performed on the server side, and
should be done using a whitelist of known good data. Instead of searching the data for bad
characters, check that the string matches the expected format based on the type of input.
For example, if the user controlled data is a postal zip code, validate that the data is
numeric, rather than searching the data for “<” characters. It is always harder to enumerate
the possible bad data, than to enumerate the possible good data. Validating user controlled
data before use is simply the correct way to write code, and along with helping to prevent
XSS vulnerabilities, will make the application run more smoothly as a whole. Output
encoding can then be used for further protection, catching any data that could not be
cleaned during input validation.

Internal Use Only
Cross Site Flashing (XSF)
Flash applications can also be vulnerable to a similar issue to XSS. When your Flash
application uses functions which invoke JavaScript or retrieve URLs, you must check the
data you pass to these functions. If the data is user controlled, than an attacker can enter
malicious JavaScript or pass a malicious URL. Sometimes, the attacker may be able to load
their own malicious SWF inside of the application due to such dangerous use of the
loadMovie function. A common mistake is to pass data from flashvars to these dangerous
functions. For more information see the following resource:
http://www.adobe.com/devnet/flashplayer/articles/secure_swf_apps.html
XSS in Facebook applications

XSS attacks in Facebook applications are unusual due to the use of FBML, FBJS, XFBML,
and the Facebook proxy.
XSS in Facebook iFrame applications

In an XSS attack, the injection occurs in the domain of your application. If the injection is
possible due to a lack of input validation and output encoding in the application code, then
the attacker can execute arbitrary HTML and JavaScript; and in some cases XFBML. The
injected code can be used to steal any Facebook cookies which are set when using
Facebook Connect code. These cookies reveal the user session key.

Internal Use Only
XSS in FBML/FBJS applications
In an XSS attack on FBML applications, the injected data will be written directly to the
source of the page in the apps.facebook.com domain. However, as part of the Facebook
sandboxing method for FBML applications, any injected script will be translated to FBJS.
This means that an attacker cannot send the traditional XSS payload which, for example,
uses JavaScript to access the user session. However, the attacker can still easily inject
arbitrary FBML tags. When an attacker can inject FBML, they can do things like inject an
FB:SWF tag (< fb:swf /> ), which embeds a SWF in the application canvas page. Whenever
a SWF is loaded in the application canvas, Facebook will automatically pass it all of the
Facebook parameters, including the session secret, as flashvars. The attacker can then
send the flashvars back to their server and then use this information to access the
application and perform actions on behalf of the user.
Considerations for Flash Applications

There are a few things to keep in mind when creating Facebook applications with Flash.
Some of the information in this section may overlap with other sections, but is presented
from the perspective of Flash applications.
To better understand the issues facing Flash applications, let us consider a fictional Flash
based iFrame platform application called “Goatworld”, which is a game where players build
teams of goat buddies with their Facebook friends. Users can send goat buddy requests to
their Facebook friends, and the more goat buddies the user has, the higher level they obtain
in the game.

Internal Use Only
The application is built using Flash, and runs from a SWF hosted in an iFrame on the
application canvas page. The Facebook parameters are automatically passed to the
application in the GET request which retrieves the hosting iFrame. The hosting page takes
these Facebook parameters and passes them to the Flash application as flashvars. The
Flash application then uses these parameters to make calls to Facebook using the
ActionScript API. When the game loads, the SWF uses the fb_sig_user parameter to
discover the current user’s goat buddies, and then sets the player’s level accordingly.
Unfortunately, the hosting page does not validate the Facebook parameters before passing
them to the Flash application. This allows an attacker to intercept the request to the hosting
page, and change the fb_sig_user parameter to that of a different Facebook user, who has
many goat buddies. Then, when the Flash application makes the call to retrieve the user’s
goat buddies, it will retrieve the list of the other user’s friends. This allows the attacker to
discover the Facebook friends of other users, in addition to providing them with a way to
cheat in the game. This exemplifies that the Facebook signature must always be verified
when trusting the Facebook parameters. However, there are also other ways that an
attacker can manipulate the flashvars passed to a SWF. This has to do with the cross
domain communication policy configuration.

Internal Use Only
Cross
cross domain
By default, the Flash runtime enforces the same origin policy and SWFs are only allowed to
connect back to their domain of origin. If the SWF needs to communicate to servers other
domain than its domain of origin, the crossdomain.xml policy file must be in place to grant access.
policy The cross domain.xml policy will grant communication to that server from SWFs hosted on
police the domains specified. When a SWF attempts to make the connection, it will check for the
crossdomain.xml file in the web root of the domain it is attempting to connect to. It is very
important to properly configure this policy file so that it restricts the access it allows.
A dangerously configured crossdomain.xml is as follows:
< cross-domain-policy>
< allow-access-from domain="*"/>
< /cross-domain-policy>
This dangerous configuration allows access from any domain, effectively enabling Flash
content on any site to attack your application. This would allow an attacker to host your
SWF on their site, and although the SWF’s domain of origin is now the attacker’s, the SWF
can still make calls back to its original domain because of the badly configured
crossdomain.xml file in place. This gives the attacker control of the flashvars the SWF uses,
and would allow the attacker to, for example, provide a different value for the fb_sig_user
parameter and other Facebook parameters passed to the SWF. This also allows any
domain to make cross domain AJAX calls to your server, read data, and send custom
headers with requests. This can lead to a whole host of serious issues.

Internal Use Only
Only configure a crossdomain.xml file that grants access only the specific, trusted, domains
the SWF needs to connect from.
For example, consider a SWF whose domain of origin is sometimes foo.example.com, and
sometimes bar.example.com, but it always needs to call back to code on example.com. The
policy file hosted at example.com should then look like this:
< cross-domain-policy>
< allow-access-from domain="foo.example.com"/>
< allow-access-from domain="bar.example.com"/>
< /cross-domain-policy>
This will allow the SWF to be hosted at either the foo or bar sub domains, but will not allow it
to be hosted at the attacker’s site. Furthermore, it will not allow arbitrary domains access to
the server through cross domain requests.
More detail on cross domain.xml policy files can be found at

http://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html .
More information on development using Flash can be found at

http://www.adobe.com/devnet/facebook/ .

Internal Use Only
HTTPS Secure transport using SSL

HTTPS
protocol The HTTPS protocol provides the ability to transport information securely over the network
using public key cryptography. The protocol provides confidentiality and integrity
protocol guarantees. When communicating over HTTPS, one can have some confidence on who
they are talking to and that the data sent cannot be successfully tampered with. Without
using HTTPS there can be no such guarantee. Facebook does not serve its own content
over HTTPS. However, it is still possible to leverage the security benefits of an HTTPS site
using Facebook Connect. The following guide discusses how to use Facebook Connect with
an SSL site: http://wiki.developers.facebook.com/index.php/Facebook_Connect_Via_SSL.
Areas of an application which deal with financial transactions, such as online payments,
must use HTTPS to protect their communications. If you are writing a Facebook application
that has a payments component, consider the following recommendations for integrating
securely with Facebook.
Ensure sensitive API calls use HTTPS endpoints

When making sensitive API calls, ensure that they are sent over HTTPS by calling them
from an HTTPS endpoint. For example, the function auth.getSession returns the user’s
session secret, which can be used to make sensitive API calls on behalf of the user. For
client side applications, the session secret is used in place of the application secret, and
therefore must be guarded carefully. Calls to auth.getSession should be made to an HTTPS
endpoint, so that it will be returned to the client application over a secure connection. The
same applies for other sensitive server side APIs.

Internal Use Only
Ensure sessions with the secure site are initiated over

HTTPS
When a Facebook platform application which is served over HTTP needs to direct the user
to a secure site (for example to start a financial transaction), it is crucial that the session be
initiated over HTTPS. A common mistake is to direct the user to the secure site using HTTP,
and then internally redirect to the HTTPS connection after, without changing the session
identifier. This is dangerous as it reveals the session identifier in the clear, before redirecting
to the HTTPS site. In the best case, the secure site should not be accessible over HTTP
at all.
Set the secure flag on all sensitive cookies

Setting the Secure flag on cookies tells the browser to only send the cookie over an HTTPS
connection. This will keep sensitive cookies from being revealed to network attackers. Not
setting the Secure flag severely undermines the protections provided by HTTPS, as the
secure session can still be compromised.

Internal Use Only
Administrativ Administrative functionality

eadministrative Because the Facebook platform is different than traditional application platform, securing
administrative functionality can be confusing, and some compromises have to be made.
Developers of a Facebook application can set certain users to be administrators and
moderators of the application. There are certain API functions that can only be called by
administrators. These functions provide the ability to perform administrative actions for the
Facebook application, such as banning and unbanning users, setting application properties,
and retrieving information about the applications usage statistics. It is tempting to include
these functions in the same application canvas as the normal user functionality.
Unfortunately, this design goes against the principle of least privilege. It is a best practice to
keep the administrative functionality as separate as possible from the normal user
application. For Facebook applications, the following recommendations should be
considered in order to secure administrative functionality.
Require HTTPS
Any administrative pages must be served only over HTTPS in order to protect from local
network attackers. This should be followed even if the administrative portion of the
application is served only internally, to protect from rogue insider attacks. The application
can still use the Facebook API by using Facebook Connect with SSL to authenticate and
then transferring the session to the server side in order to make admin API calls which
require the application secret. The session transfer process is described in detail here:
http://wiki.developers.facebook.com/index.php/Using_Facebook_Connect_with_Server-
Side_Libraries.

Internal Use Only
Host administrative functionality on a different domain

It can be tempting to host the administrative portion of the application on the same domain
as the rest of the application. One common scenario is to check if the Facebook ID sent with
the request is an administrator’s ID and then to display the corresponding administrative
functionality in the same Facebook canvas page as the rest of the application. This is not
recommended as it can allow for XSS attacks to have a more devastating effect, and can
make it easier for an attacker to discover the administrative pages in order to perform CSRF
attacks. Instead, the administrative functionality should be hosted on an entirely separate
domain. The application can still use the Facebook API by using Facebook Connect and
transferring the session to the server side API for calls which require the application secret.
Make endpoints available internally only

The application should only be available on the internal network. As a rule, administrative
interfaces should never be available from the internet. Internal only hosting will greatly
increase the difficulty of attacking the application, as the attacker will first have to gain
access to the internal network.
Require additional authentication

The administrative portion of the application can use Facebook Connect to log into the
application via Facebook credentials. However, Facebook sessions are not secured over
HTTP, so there is a potential for hijacking an administrators session. If an administrator’s
session is hijacked by an attacker, they may be able to use that session to access the
administrative functionality. In order to provide further protection, require administrators to
log into the application using separate credentials.

Internal Use Only
References
The Open Web Application Security Project –
references https://www.owasp.org/index.php/Facebook

Internal Use Only

Internal Use Only
web services
Description .................................................................... 7.12.3

contents Value ......................................................................................................................... 7.12.3
Area of use ................................................................................................................ 7.12.3
Detail ............................................................................ 7.12.4

REST Web services .................................................................................................. 7.12.4
SOAP Web services.................................................................................................. 7.12.8
When to use REST vs. SOAP ................................................................................... 7.12.8
Reference ................................................................... 7.12.10

Internal Use Only
web services
Description This standard addresses using REST and SOAP in the development
of web services for use in both internal and external applications.
description The document provides a description of each method, and best
practices for when to use each method.
Value
Through consistent implementation and standard based interface definition, robust service
oriented architecture solutions can be developed and integrated. Common tools can be
used and cost can be reduced.
Area of use
This standard applies to application-to-application communication for applications and
components deployed that have the following characteristics:
 "Request and response" pattern for the communication
 XML for both request and response messaging and/or message payload.
 HTTP, HTTPS, MQ Series, or JMS (Java Messaging Service) as the interface

transport
 APIs

Internal Use Only
web services
Detail REST Web services

REST defines a set of architectural principles by which you can design Web services that
detail focus on a system's resources, including how resource states are addressed and
transferred over HTTP by a wide range of clients written in different languages.
A concrete implementation of a REST Web service follows four basic design principles:
Use HTTP methods explicitly

This basic REST design principle establishes a one-to-one mapping between create, read,
update, and delete (CRUD) operations and HTTP methods. According to this mapping:
 To create a resource on the server, use POST.
 To retrieve a resource, use GET.
 To change the state of a resource or to update it, use PUT.
 To remove or delete a resource, use DELETE.
 Be stateless.
 Expose directory structure-like URIs.
 Transfer XML, JavaScript Object Notation (JSON), or both.

Internal Use Only
web services
Be stateless
Recommended
REST Web services need to scale to meet increasingly high performance demands.
Clusters of servers with load-balancing and failover capabilities, proxies, and gateways are
typically arranged in a way that forms a service topology, which allows requests to be
forwarded from one server to the other as needed to decrease the overall response time of
a Web service call. Using intermediary servers to improve scale requires REST Web service
clients to send complete, independent requests. This means clients are required to send
requests that include all data needed to be fulfilled so that the components in the
intermediary servers may forward, route, and load-balance without any state being held
locally in between requests.
Expose directory structure-like URIs

Recommended
REST Web service URIs should be intuitive to the point where they are easy to guess. Think
of a URI as a kind of self-documenting interface that requires little, if any, explanation or
reference for a developer to understand what it points to and to derive related resources. To
this end, the structure of a URI should be straightforward, predictable, and easily
understood.
One way to achieve this level of usability is to define directory structure-like URIs. This type
of URI is hierarchical, rooted at a single path, and branching from it are subpaths that
expose the service's main areas. According to this definition, a URI is not merely a slash-
delimited string, but rather a tree with subordinate and superordinate branches connected at
nodes.

Internal Use Only
web services
Guidelines for URI structure for RESTful Web service are:
 Hide the server-side scripting technology file extensions (.jsp, .php, .asp), if any, so
you can port to something else without changing the URIs.
 Keep everything lowercase.
 Substitute spaces with hyphens or underscores (one or the other).
 Avoid query strings as much as you can.
 Instead of using the 404 Not Found code if the request URI is for a partial path,
always provide a default page or resource as a response.

Internal Use Only
web services
Transfer XML, JavaScript object notation (JSON), or both

Recommended
The objects in your data model are usually related in some way, and relationships between
data model objects (resources) should be reflected in the way they are represented for
transfer to a client application. In the discussion threading service, an example of connected
resource representations might include a root discussion topic and its attributes, and embed
links to the responses given to that topic.
Give client applications the ability to request a specific content type that's best suited for
them. Construct your service so that it makes use of the built-in HTTP Accept header, where
the value of the header is a MIME type.
Some common MIME types used by RESTful services are:

 MIME-Type Content-Type
 JSON application/json
 XML application/xml
 XHTML application/xhtml+xml

Internal Use Only
web services
SOAP Web services

SOAP is an XML-based standard for messaging over HTTP and other Internet protocols. It
is a lightweight protocol for the exchange of information in a decentralized, distributed
environment. It is based on XML and consists of three parts:
 An envelope that defines a framework for describing what is in a message and how
to process it.
 A set of encoding rules for expressing instances of application-defined data types.
 A convention for representing remote procedure calls and responses.

SOAP enables the binding and usage of discovered Web services by defining a message
path for routing messages. SOAP may be used to query UDDI for Web services.
For more information on SOAP 1.1 (SOAP 1.2 is not supported by the Web services tools),
refer to www.w3.org/TR/SOAP
When to use REST vs. SOAP

Recommended
Use REST for user interfaces and perhaps client apps, where a human is doing the work.
These apps seem to be more forgiving. If the GUI messes up, the user notices and tries
something else. REST can be especially useful with Ajax, where simplicity is prized over
correctness.

Internal Use Only
web services
Recommended
Use SOAP/WSDL for application integration, where apps are talking to each other without
human intervention or supervision. In this context, strong interfaces, provable correctness,
and management and migration of service interfaces are prized over simplicity.
So the question to be asked is: What if the interface changes and the integration breaks?
If that's no big deal or easy to fix, use REST; otherwise, use SOAP/WSDL.

Internal Use Only
web services
CAN SPAM Compliance Guide – http://business.ftc.gov/documents/bus61-can-spam-act-

compliance-guide-business
Reference
reference RESTful Web Services: the basics –
http://www.ibm.com/developerworks/webservices/library/ws-restful/

Internal Use Only
<TITLE PLACEHOLDER>
PepsiCo

STANDARD

reporting
Description .................................................................... 7.13.3

contents Value ......................................................................................................................... 7.13.3
Detail ............................................................................ 7.13.4

Outage reporting ....................................................................................................... 7.13.4
Web Analytics ........................................................................................................... 7.13.4
Hardware reporting ................................................................................................... 7.13.5
Online template ......................................................................................................... 7.13.5

Internal Use Only
reporting
Description The Reporting Standard outlines basic categories of information and

data types for recording system performance statistics in a
description consistent periodic manner. Categories include Outage Reporting,
Web Analytics, and Hardware Reporting.
Value
Establishing a common set of reporting criteria provides the means to establish norms and
recognize fluctuations for individual systems, as well as to compare and analyze information
across different systems.

Internal Use Only
reporting
Detail Outage reporting

Four outage categories, with four associated data points, are defined:
detail
1. Hardware
 Time occurred
2. Application  Length of outage
3. Host OS  Outage severity
 Reason for outage
4. Network
Web Analytics
Key metrics and key performance indicators (KPIs) to be reported are based on categories
from the Web Analytics Association:
Basic ratios KPIs by site type: KPIs by process:

 Content sites  Reach
o Advertising-based  Acquisition
o Subscription-based  Conversion
 Customer Service  Retention
 Commerce
 Lead Generation

Internal Use Only
reporting
Hardware reporting
Weekly hardware reporting will include these categories, each with different associated data
points to be captured:
 CPU
 Network
 Services
Online template
The Reporting Standard spreadsheet is available as a template to capture and report
data. The template is a Microsoft Excel file on PepsiCo’s Agency Portal under the Forms,
Tools & Reference section.

Internal Use Only
reporting

Internal Use Only
125
test acceptance flowchart
Planning phase ............................................................... 8.1.3

contents Designing and concepting phase .................................... 8.1.4
Development phase part 2 .............................................. 8.1.6
Development phase part 3 .............................................. 8.1.7

Internal Use Only

Internal Use Only
Designing & Concepting Phase

Internal Use Only

Internal Use Only
Development Phase
Part 2

Internal Use Only

Internal Use Only

Internal Use Only
<TITLE PLACEHOLDER>
PepsiCo

STANDARD

work product examples
Objective ......................................................................... 8.2.3

contents Online template............................................................... 8.2.3
Architecture & design...................................................... 8.2.4
Logical architecture diagram ....................................................................................... 8.2.4
System architecture diagram....................................................................................... 8.2.5
Architectural flow diagram ........................................................................................... 8.2.7
Network architecture ................................................................................................... 8.2.8
Database overview ....................................................... 8.2.10

User privilege table ................................................................................................... 8.2.10
Deployment matrix ........................................................ 8.2.11

Testing results .............................................................. 8.2.12
Security/audit test summary ...................................................................................... 8.2.12
Performance test summary ....................................................................................... 8.2.12
User acceptance test summary ................................................................................. 8.2.13

Internal Use Only
Objective The web certification process validates the readiness of PepsiCo

websites to process information within a technical infrastructure,
objective ensuring user capacity and acceptable performance.
The certification process also validates that the website is hosted within an environment that
meets PepsiCo infrastructure and application security standards that are defined by
PepsiCo’s Business + Information Solutions (BIS) and Information Security Group (ISG)
functions. This document.
Online See the Web Application Certification online template on PepsiCo’s Agency Portal under
online
template
the Tools, Forms & Templates section.
template The following pages give examples of work products that may be required during the
certification process.

Internal Use Only
Architecture & Logical architecture diagram

architecture
design Figure 1
& design The logical architecture diagram depicts the various

layers of the architecture, the components, and the
functionality associated with the components of each
layer. Each architectural layer exhibits a certain set of
characteristics and constraints. Architecture
components, when identified, are evaluated against the
characteristics of the architecture layers and the
evaluation yields a grouping of the architecture
components into layers. The architecture layers provide
a logical separation of architecture components.

Internal Use Only
System architecture diagram
Figure 2
The system architecture diagram depicts
the components of the architecture and
how the components interact with each
other. It provides an additional level of
detail and shows the main nodes of the
architecture. The nodes are components
with a clearly defined functional role to
play in the architecture. Well-structured
application programming interfaces
(APIs) and protocols are required
between nodes. The nodes are logical
constructs and do not correspond directly
to servers.

Internal Use Only
It is recommended to provide a description of each node. Figure 2 has multiple nodes within
the diagram. At minimum, a one line description should be used to describe each node.
Some examples for describing the nodes above are as follows:
 Akamai will grab data from the origin that is expired from its cache or not in its cache.
 The Tribal Firewall – resides in the demilitarized zone (DMZ) and allows only HTTP
traffic to enter into the network.
 The load balancers distribute load across the Zend platform.

Internal Use Only
Architectural flow diagram
Figure 3
Architectural flow diagram

Internal Use Only
Figure 4
Network communication
Network architecture
protocol diagram
Network protocol diagram
The Network Communication Protocol Diagram illustrates the
communication between the various nodes within the solution.
Figure 4 shows an example network protocol diagram.
Highlights of the Network Protocol Diagram
 Drupal, SOLR and the Zend Platform communicate

to the MySQL database via MySQL’s database
protocol.
 The Zend Platform communicates to the voting and

email servers over SSL through the firewall.
 The Apache servers communicate to the Akamai

server and Zen Platform over both HTTP and
HTTPS.

Internal Use Only
The Network Protocol Diagram (NPD) gives a simple overview of network interactions. The
NPD is often used with a protocol table that provides an overview of the protocols used by
the solution. Table 1 is an example protocol table used for the NPD in Figure 4.
Abbr Protocol Usage

H HTTP Browser to Web server, Web Service
HSSL HTTPS Browser to Web server, Web Service
D Database MySQL Database connectivity
S SMTP Mail
Table 1

Internal Use Only
Database The database overview provides an overview of pertinent user information to be used with
database the database capacity and in planning for proper sizing and user configuration. The
overview database overview can contain visual depictions of the databases and how they interact
overview with various applications within the solution.
User privilege table

Table 2 depicts an example user layout and overview that describes the database at a high
level. The table defines the users and the permissions they require for each table. The best
practice is to give each user access only to the minimum level of permissions required to
perform the actions needed by that user.
Zend front end database
Database name Pepsi_re_web

Database description Web site content, submitted and approved ideas, voting results vote leader board.
This database is used by the Zend front end for managing improvements and
Comments suggestions.
Database user Access C,R,U,D Table/tables
Pepsi_sumitter C,u All
Pepsireader R All
Pepsiadmin C,r,u,d All
Table 2

Internal Use Only
Deployment The Deployment matrix shows the mapping between software (deployment units) and the
deployment logical servers (nodes) by convention. Nodes are shown in the columns (with the column
matrix headers as the node names) and deployment units as rows. The deployment units should
matrix contain the version number of each software selection being deployed.
PHP
Content application
Software Web server Search management Database server Version
RedHat
enterprise linux X X X X X 5.4
Apache HTTP
server X X 2.0.63
MySQL
enterprise
edition X 5.0.51
Drupal X 6.1
Solr X 1.4.0
Java X X 1.6.6
JBOSS WEB X 1.4
Zend platform
server X 3.6.3
Table 3

Internal Use Only
Testing Security/audit test summary

testing
results A security audit should be conducted for medium to high visibility and high risk websites.
Once complete, the vulnerabilities, mitigation and target fix dates should be identified.
results Refer to the Web Application Security Standards for guidelines.
Vulnerability Mitigation Target date
Performance test summary

Load and performance testing should be performed for high visibility, first of a kind, and high
traffic sites. The performance test should include peak load results and sustained load
results based on the hardware capacity plan. The summary should provide the performance
goals, an overview of the peak load and sustained load testing plan, and the results of the
performance tests. Any defects found during performance testing that are not resolved
should be listed with a mitigation plan, severity, along with the target fix date.
Vulnerability Mitigation Target date

Internal Use Only
User acceptance test summary

System and User Acceptance Testing should be performed on all sites. Any defects found
during System and User Acceptance testing that are open should be documented with a
target fix date and mitigation plan.
Defect severity Mitigation Target date

Internal Use Only

Internal Use Only
<TITLE PLACEHOLDER>
PepsiCo
Web Application Deployment Plan

WEB CERTIFICATION

web application deployment plan
Pre-deployment plan ....................................................... 8.3.3

contents Deployment plan ............................................................. 8.3.3
Post-deployment plan...................................................... 8.3.4
Roll back plan .................................................................. 8.3.4
Contact list ...................................................................... 8.3.5
Escalation ........................................................................ 8.3.5

Internal Use Only
Pre-deployment plan
Step Instruction Command Owner Duration
1
Deployment plan
Clean Deploy working rm -rf <deploy working System 5 min
1
directory directory>/* Admin
Move Build zip file into unzip deploy- System
2 <deploy working myapplication<drop_date><vers Admin
directory> ion>.zip
Setup Oracle . ./setdbenv.oracle.sh System
3 Environment. Admin
./setdbenv.oracle.sh
Login to database System
4 Admin
Run SQL script. @file System
5 Admin
Run Deploy Ant script cd <deploy working directory> System
6 Admin
./ant -f deploy.xml - System
Dtarget.env=qat1 - Admin
6.1
Dbuild.label=<build_label> -
Ddeploy.type=full

Internal Use Only
Post-deployment plan
1
Roll back plan

1

Internal Use Only
Contact list
Name Email Phone Title
Escalation
Name Email Phone Title

Internal Use Only

Internal Use Only
glossary of terms
Application Development ................................................ 9.1.3

contents Compliance ..................................................................... 9.1.5
Encryption ....................................................................... 9.1.6
Facebook ........................................................................ 9.1.7
Core concepts ............................................................................................................. 9.1.7
Legacy APIs ................................................................................................................ 9.1.8
Software Development Kits – (SDKs) ......................................................................... 9.1.8
Tools ........................................................................................................................... 9.1.9
Testing .......................................................................... 9.1.11

Internal Use Only
glossary of terms
Application
AJAX (Asynchronous JavaScript and XML). A group of inter-related web development methods used on the
application
client-side to create interactive web applications; web applications can retrieve data from the server
asynchronously in the background without interfering with the display and behavior of the existing page.
Development
development DHTML (Dynamic HTML). A collection of technologies used together to create interactive and animated web
sites by using a combination of a static markup language (such as HTML), a client-side scripting language (
such as JavaScript), a presentation definition language (such as CSS), and the Document Object Model.
GUID (Globally Unique Identifier). A special type of identifier used in software applications to provide a unique
reference number. The primary purpose of the GUID is to have a totally unique number; ideally it will never
have to be generated twice by any computer or group of computers in existence.
IHS (IBM HTTP Server). Based on the Apache HTTP Server; can be remotely administered and configured
using the WebSphere administrative console; the HTTP server is also included in the IBM WebSphere
Application Server distribution packages.
JDK 1.4.2 (Java 2 SDK, Version 1.4.2). An upgrade release of the Java platform; provides support for several
cryptographic algorithms commonly used in cipher suites such as RSA, RC4, DES, Triple DES, Diffie-Hellman,
and DSA; provides server session management APIs to manage memory-resident SSL sessions; provides
support for cipher suite negotiation, which is part of the SSL handshaking used to initiate or verify secure
communications.
JSON-RPC (JSON Remote Procedure Call). A protocol similar to XML-RPC defining only a handful of data
types and commands; allows for bi-directional communication between the service and the client, treating
each more like peers and allowing peers to call one another or send notifications to one another.
ORM (Object-Relational Mapping). A programming technique for converting data between incompatible type
systems in object-oriented programming languages. ORM creates a "virtual object database" that can be used
from within the programming language.
PHP (Hypertext Preprocessor). A widely used, general-purpose scripting language that was originally
designed for web development to produce dynamic web pages; embedded into the HTML source document
and interpreted by a web server with a PHP processor module, which generates the web page document.
QR Codes (Quick Response Codes). Specific matrix code, readable by dedicated QR barcode reader and
camera phones; code consists of black modules arranged in a square pattern on a white background; the
information encoded can be text, URL, or other data.

Internal Use Only
glossary of terms
RSS feed (Really Simple Syndication feed). A family of web feed formats used to publish frequently updated
networks – such as blog entries, news headlines, audio, and video – in a standardized format. An RSS
document includes full or summarized text, plus metadata such as publishing dates and authorship.
SOA (Search-Oriented Architecture). Architecture in which the data tier may be replaced or placed behind
another tier which contains a search engine and search engine index which is queried in-place of the database
management system; the search engine crawls the relational database management system in addition to
other traditional data sources such as web pages or traditional file systems and consolidates the results when
queried.
SOAP (Simple Object Access Protocol). A protocol specification for exchanging structured information in the
implementation of Web Services in computer networks; relies on Extensible Markup Language (XML) for its
messaging format, and usually relies on other Application Layer protocols for message negotiation and
transmission; can form the foundation layer of a web services protocol stack, providing a basic messaging
framework upon which web services can be built.
Solr. An open source enterprise search platform from the Apache Lucene project; its major features include
powerful full-text search, hit highlighting, faceted search, dynamic clustering, database integration, and rich
document handling; provides distributed search and index replication.
Spring MVC (Spring Model-view-controller). A request-based framework; defines strategy interfaces for all of
the responsibilities which must be handled by a modem request-based framework; the goal of each interface is
to be simple and clear so that it's easy for Spring MVC users to write their own implementations if they so
choose.
UAT (Universal Audio Transmitter). A wireless bridge which allows wireless control over common media
players such as iTunes, Pandora Radio, and Windows Media Player.
VLAN (Virtual Local Area Network). A group of hosts with a common set of requirements that communicate as
if they were attached to the same broadcast domain, regardless of their physical location; allows for end
stations to be grouped together even if they are not located on the same network switch.
XML (Extensible Markup Language). A set of rules for encoding documents in machine-readable form; the
design goals emphasize simplicity, generality, and usability over the Internet.

Internal Use Only
glossary of terms
Compliance
AML (Anti-Money Laundering). Describes the legal controls that require financial institutions and other
regulated entities to prevent or report money laundering activities.
compliance GLB (Gramm-Leach-Bliley Act). Allows commercial banks, investment banks, securities firms, and insurance
companies to consolidate.
PCI (Payment Card Industry standard). A set of data security requirements designed to ensure that all
companies that process, store, or transmit credit card information maintain a secure environment.
SARBOX or SOX (Sarbanes Oxley Act). Legislation intended to drive public corporations and organizations
toward a higher bar of financial responsibility and reporting; states that companies must guarantee the
accuracy of all financial reports; requires companies to put investors on notice when financial situations
change; requires companies to prepare reports evaluating their company's internal executives effectiveness at
meeting these guidelines.
SAS 70 (Statement on Auditing Standards No. 70: Service Organizations). Provides guidance to service
auditors when assessing the internal controls of a service organization and issuing a service auditor's report;
provides guidance to auditors of financial statements of an entity that uses one or more service organizations.

Internal Use Only
glossary of terms
Encryption
AES (Advanced Encryption Standard). A symmetric-key encryption standard adopted by the U.S. government;
comprises three block ciphers adopted from a larger collection; the cipher is specified as a number of
repetition of transformation rounds that convert the input plaintext into the final output of cipher text.
encryption COPPA (Children's Online Privacy Protection Act). Legislation regarding the online collection of personal
information by persons or entities under U.S. jurisdiction from children under 13 years of age; it details what a
website operator must include in a privacy policy, when and how to seek verifiable consent from a parent or
guardian, and what responsibilities an operator has to protect children's privacy and safety online.
PGP (Pretty Good Privacy). A data encryption and decryption computer program that provides cryptographic
privacy and authentication for data communication; often used for signing, encrypting and decrypting emails to
increase the security of email communications.
RDA (Remote Database Access). A protocol for database access; describes the connection of a database
client to a database server; includes features for communicating database operations and parameters from the
client to the server, in return, transporting result data from the server to the client; database transaction
management.
RSA (Rivest, Shamir, and Adleman). An algorithm for public-key cryptography; widely used in electronic
commerce protocols and is believed to be secure given sufficiently long keys and the use of up-to-date
implementations; messages encrypted with the public key can only be decrypted using the private key.
SFTP (SSH File Transfer Protocol). Specific matrix code, readable by dedicated QR barcode reader and
camera phones; code consists of black modules arranged in a square pattern on a white background; the
information encoded can be text, URL, or other data.
SPI (Security Parameter Index). An identification tag added to the header while using IPsec for tunneling the
IP traffic; help the kernel discern between two traffic streams where different encryption rules and algorithms
may be in use.
SSH (Secure Shell). A network protocol that allows data to be exchanged using a secure channel between two
networked devices' used basically on Linux and Unix based systems to access shell accounts.
SSL (Secure Sockets Layer). A cryptographic protocols that provide communications security over the
internet; encrypt the segments of network connections above the Transport Layer, using symmetric
cryptography for privacy and a keyed message authentication code for message reliability.

Internal Use Only
glossary of terms
Facebook
Apps on Facebook.com. Building an app on Facebook.com gives you the opportunity to deeply integrate into
our core user experience. Use the native functionality of Facebook such as Request and Bookmarks to create
an ideal social space for your users.
Facebook Mobile apps on Facebook. The Facebook platform makes iOS (iPhone & iPad), Android, and Mobile Web
applications social. Use single-sign-on to access the user's social graph (without yet another
username/password) and create a personalized experience.
Websites. Using Facebook on your website allows you to create more a personalized, social experience using
social plugins such as the Like Button and simplify your registration and sign-in process using Login button
and Registration plugin.
Core concepts
Authentication. Facebook authentication enables your app to interact with the Graph API on behalf of
Facebook users and provides a powerful single-sign on mechanism across Web, mobile, and desktop apps.
Graph API. The Graph API is the core of Facebook platform, enabling you to read and write data to Facebook.
It provides a simple and consistent view of the social graph, uniformly representing objects (like people,
photos, events, and pages) and the connections between them (friendships, likes, and photo tags).
Open graph protocol. The Open Graph protocol enables you to integrate your pages into the social graph.
These pages gain the functionality of other graph objects including profile links and stream updates for
connected users.
Social channels. Facebook platform lets you integrate with social channels such as News Feed and
Requests to help you drive growth and engagement with your app, site or content.
Social plug-ins. Social plugins enable you to provide engaging social experiences to your users with just a
line of HTML. Because the plugins are served by Facebook, the content is personalized to the viewer whether
or not they have signed into your site.

Internal Use Only
glossary of terms
Legacy APIs
Legacy FBML. FBML enables you to build Facebook applications that deeply integrate into a user's Facebook
experience. To use JavaScript within FBML, use FBJS.
Legacy JavaScript API. The old Javascript API provides a rich client-side functionality for authentication and
rendering Dialogs.
Legacy REST API. The REST API enables you to interact with Facebook web site programmatically via HTTP
requests.
Software Development Kits – (SDKs)

Android SDK. Android SDK brings the Facebook platform to the Android platform (mobile & devices). You can
use this SDK to add single-sign-on to your Android apps, invoke the Graph API and more.
iOS SDK. The iOS SDK provides first-class Facebook platform support for iPhone, iPad and iPod Touch apps
written in Objective-C. You can utilize single-sign-on, call the Graph API and display platform dialogs.
JavaScript SDK. The JavaScript SDK enables you to access all of the features of the Graph API and dialogs
via JavaScript. It provides a rich set of client-side functionality for authentication and rendering the XFBML
versions of our social plugins.
PHP SDK. This SDK provides Facebook platform support to your PHP-based web apps. This library helps you
add Facebook login and Graph API support to your website.
Python SDK. This open source library provides limited support for the Facebook platform inclusive of making
Graph API calls and supporting authentication cookies set by the JavaScript SDK.

Internal Use Only
glossary of terms
Tools
Ads API. The Facebook Ads API lets you create and manage your own ads on Facebook programmatically,
without using the Facebook Advertising Manager tool. http://www.facebook.com/ads/manage/
Change Log. We make sure to inform Facebook platform developers about any notable changes through our
developer blog, but we know that even minor changes can sometimes impact developers, so we provide a
change log at this url: http://developers.facebook.com/blog.
Chat API. You can integrate Facebook chat into your Web-based, desktop, or mobile instant messaging
products. Your instant messaging client connects to Facebook chat via the Jabber/XMPP service.
Credits API. The Facebook Credits API enables a user to use credits as a method for purchasing digital and
virtual goods within your app.
Developer App. The Developer app allows you to create and manage Facebook apps.
Dialogs. Dialogs provide a simple, consistent interface to display dialogs to users. Dialogs do not require
special user permissions because they require user interaction. Dialogs can be used in any type of application,
whether on Facebook.com, a website, or a mobile application.
FQL (Facebook Query Language).Enables you to use an SQL-style interface to query the data exposed by the
Graph API. It provides for some advanced features not available in the Graph API, including batching multiple
queries into a single call.
Insights. Insights provide analytics on your Facebook page, app and website. The Insights dashboard makes
it easy to see how Facebook users are interacting with your content, and the Insights APIs allow developers to
obtain additional Insights and integrate the data with third party reporting systems.
http://www.facebook.com/insights.
Internationalization API. Facebook is currently available in over 70 languages, thanks to a framework that
allows our user community to translate the text on Facebook. By integrating with Facebook, you can take
advantage of our Translations framework immediately, so you can enjoy the benefits that translation can bring
to your platform application or website.

Internal Use Only
glossary of terms
JavaScript test console. A simple way to learn, test and, debug the JavaScript SDK. It also includes a large
number of working examples: http://developers.facebook.com/docs/reference/javascript/.
Live Status. Having unexpected problems with our APIs? Before filing a bug, check Live Status to see if we
know about it, and if it’s affecting everybody.
Test Users. A test user is a user account associated with an app created for the purpose of testing the
functionality of that application. The Facebook platform supports the creation of test users for manual and
automated tests.
URL linter. Tool that helps you debug your Open Graph protocol pages. Having problems with the Like button
or our other social plugins? Start with URL linter.

Internal Use Only
glossary of terms
Testing
Audit and controls testing. Verify the adequacy and effectiveness of controls and the completeness of data
processing results.
testing Backup and recovery testing. Verify the capability of the application to be restarted after a failure.
Defect. A variance from expectations.
Entry criteria. A checklist of activities that must be completed or work items that must exist before a given
task within an activity or sub-activity may begin.
Error-handling testing. Verify the ability of the application to detect and respond to exception conditions. For
example, test to ensure that correct error messages are returned for invalid entries.
Exit criteria. Actions that must happen before an activity is considered complete.
Function testing. Verify that each business function operates according to the detailed requirements and the
external and internal design specifications.
Integrated test. Interconnectivity test, end-to-end test and user acceptance test.
Integration testing. Verify proper execution of all the application components, including interfaces to other
applications. Tests are performed to verify that the system is both functionally and operationally sound.
Interface system testing. A test type used to ensure that all interfaces and links between applications or
systems are functioning correctly.
Operational testing. Verify that all components are operational and function properly.
Performance testing. Verify that the system meets the level of performance expected, including response
times, turnaround times (throughput), and availability.
Regression testing. Verify that no unwanted changes are introduced anywhere in the system as a result of
one part of the system changing. It verifies that the system functions as a whole.

Internal Use Only
glossary of terms
Security testing. Verify that security features perform as intended, including logons, passwords, file
protections, restricted access, etc.
Stress/volume testing. Test data is used to test the boundaries, perimeters, or extremes of the input domain.
Stress testing often includes maximum, minimum, and between values. High volumes of traffic are generated
to test how the system responds.
System testing. A dynamic level of testing in which all the components that comprise a system are tested to
verify that they function together as a whole.
Test case. A set of test inputs, execution conditions, and expected results developed for a particular objective,
such as to exercise a particular program path or to verify compliance with a specific requirement.
Test data. The input data and file conditions associated with a specific test case.
Test environment. The external conditions or factors that can directly or indirectly influence the execution and
results of a test.
Unit testing. The first verification of new or changed code in a component to determine whether the logic,
syntax and, modified paths function correctly.
Usability testing. Verify the simplicity and/or user-friendliness of an application.
User acceptance testing. A level of testing conducted by the user of the system. The user performs their
daily, weekly, monthly, quarterly, and/or annual functions on the test environment. The objective is to ensure
that the modifications have not affected the user community.

Internal Use Only

DIG Book PI Web

Uploaded by

Copyright:

Available Formats

DIG Book PI Web

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DIG Book PI Web

Uploaded by

Copyright:

Available Formats

PepsiCo

Introduction to the Playbook

DRAFT - February 23, 2011

Description ...................................................................... 1.1.3

Detail .............................................................................. 1.1.5

© 2011 PepsiCo Inc.

1.1.2 DIGITAL INITIATIVES GUIDEBOOK October 2011

Description A new digital playing field

October 2011 DIGITAL INITIATIVES GUIDEBOOK 1.1.3

PepsiCo digital initiative: single view

1.1.4 DIGITAL INITIATIVES GUIDEBOOK October 2011

Detail How to take the lead in the digital game

October 2011 DIGITAL INITIATIVES GUIDEBOOK 1.1.5

Staying grounded as the game changes

1.1.6 DIGITAL INITIATIVES GUIDEBOOK October 2011

October 2011 DIGITAL INITIATIVES GUIDEBOOK 1.1.7

1.1.8 DIGITAL INITIATIVES GUIDEBOOK October 2011

DRAFT - February 23, 2011

Objective ......................................................................... 2.1.4

© 2011 PepsiCo Inc.

2.1.2 DIGITAL INITIATIVES GUIDEBOOK October 2011

Online template............................................................ 2.1.32

October 2011 DIGITAL INITIATIVES GUIDEBOOK 2.1.3

Objective Through the Technology Capabilities Assessment, PepsiCo teams,

Proposed agency certification process (New Agency)

2.1.4 DIGITAL INITIATIVES GUIDEBOOK October 2011

October 2011 DIGITAL INITIATIVES GUIDEBOOK 2.1.5

2.1.6 DIGITAL INITIATIVES GUIDEBOOK October 2011

Information required - overview

October 2011 DIGITAL INITIATIVES GUIDEBOOK 2.1.7

*must be completed for all submissions

Contact information - example

Group QTG- Gatorade Telephone #

Email address Randall.brown@pepsico.com

Group QTG - Gatorade Telephone #

Email address Paul.Longo@Pepsico.com

October 2011 DIGITAL INITIATIVES GUIDEBOOK 2.1.9

Project approach & processes: general

2.1.10 DIGITAL INITIATIVES GUIDEBOOK October 2011

Test methodology: general

Project approach & processes: websites

October 2011 DIGITAL INITIATIVES GUIDEBOOK 2.1.11

Platforms & standards: websites

2.1.12 DIGITAL INITIATIVES GUIDEBOOK October 2011

Warranty & support: websites

Data security & transfer protocols: websites

October 2011 DIGITAL INITIATIVES GUIDEBOOK 2.1.13

Database & data collection process and procedures:

2.1.14 DIGITAL INITIATIVES GUIDEBOOK October 2011

October 2011 DIGITAL INITIATIVES GUIDEBOOK 2.1.15

Content management: websites

2.1.16 DIGITAL INITIATIVES GUIDEBOOK October 2011

Other information: websites

October 2011 DIGITAL INITIATIVES GUIDEBOOK 2.1.17

Number of registered users

Visits per day

Page views per day (average)

Page load times (average)

Number of registered users