KNOWLEDGE BASE IN APPLICATION SUPPORT

A knowledge base is a centralized repository for information: a public library, a database of related information about a particular subject. A good knowledge base is the key part of an application. All the large organization stores their issue resolutions in some type of hierarchical database. This database is termed as knowledge base. The knowledge base is not only a data repository but an intelligent tool used for providing solutions to frequently occurring issues. Knowledge base in Application Support helps in resolving the issues faster as it saves time used by the executive for analysis and identifying steps to resolve the same. The knowledge base in Application Support can also be used to store best possible solution which can help in solving respective issue or incident in optimum time. Knowledge Base in application support helps in decision making and finding solutions.

Key features:

• Easily manageable
• Simple, logical, understandable and usable
• Knowledge bases are flexible in terms of storage and technology
• Easily configurable
• Secured

How to manage Knowledge Base:

• Knowledge bases are as much as gathering information. They are only as good as their contents are accurate and accessible. Therefore, they should be set up properly from the beginning of process. An accurate knowledge base helps in easily accessing and analyzing the issues in a knowledge base which gives an advantage of solving issues faster. 

• Ideally, a knowledge base should be updated only by one person or it may lead to the collection of junk/duplicate / unwanted knowledge base data. If access is given to all the executives in the Application support team then they will upload all the resolutions they have provided on the Knowledge base. This will result in too much information. There will be multiple solutions for one single issue which will confuse the new user in identifying the best of the lot as every user might have solved that particular issue in a different way. Thus, more effort and time will be utilized by the user in solving similar issues. Hence, there should be a SME who should be responsible for uploading the solutions on the Knowledge Base. All the data should be funnelled through the SME who will make sure than only optimum solutions are uploaded in the Knowledge base. Basically, this helps in securing knowledge base content.

• When it comes to Information technology, it can never be said that the solutions deployed is fool proof and will never need an upgrade. Same rule applies for Knowledge base as well. Now a days while deploying a solution the main factors that are considered is flexibility and scalability as the need can change with time and the respective application should be able to evolve and upgrade as per the needs to help it satisfy the increasing needs and demands. Similarly a knowledge base is efficient and useful only if it satisfies the basic requirements. However, in order to evolve or upgrade a Knowledge base in the right direction which would prove useful with changing time. A process should be set-up, in which team or the end users using the Knowledge base would suggest improvements and a team will discuss those improvements on periodic basis with respect to feasibility, pricing and value addition so that the end result would be an efficient Knowledge base catering to the need of the Application support team. 

• The knowledge base can be a data file in any form. The data file in any form is acceptable but it should be understandable to everyone, should be readable and should be in proper format. 

Steps to solve an issue using Knowledge Base in Application Support:

• Step 1: The first step should be a knowledge base having an exact search filter which helps in searching exact data to be required. Also, the user should identify keyword for the raised issue so that he can search in the knowledge base with respect to keyword. In case, if related keyword does not exist in the knowledge base then he can implement a new technique / new thoughts of solving the issue.

• Step 2: The next step is to search for new ideas or thoughts to solve the issue. The new ideas / thoughts can be drafted separately and can be verified by the SME’s. Further, SME upgrades Knowledge Base with the newer version, thus releasing a new version of Knowledge Base.

• Step 3: In this step, a new user joining an organization accesses an updated knowledge base which helps him/her in resolving issues faster. In order to find updated solutions user should have access to knowledge base. If not then he should raise a request with internal support desk to grant an access.

• Step 4: Further step is to analyse issue and find a solution to that issue using the knowledge base data. Resolve issue in minimum time and upgrade knowledge base (if required).

• Step 5: Close the request

Conclusion:

The Knowledge Base in Application Support improves technical, procedural and process support. A Knowledge Base in Application Support keeps us updated with the news, announcements, information and upgrades. It is necessary to have a good knowledge base for the smooth working of Application Support project.

About Author:

Mikhil Chauhan is a consultant in Systems Plus Pvt. Ltd. Within Systems Plus, he actively contributes to the areas of Technology and Information Security. He can be contacted at: mikhil.chauhan@spluspl.com

Common Issues in Change Management

We have been hearing about Change management and the process to implement the same. But we all are aware, how challenges with change management were consistent across all of the enterprises irrespective of vertical focus and still persist to some extent. As observed, few very evident themes around these challenges were generally related to difficulty handling emergency changes to material systems, unauthorized changes, and problems dealing with security and unauthorized access. We also well aware know that auditors tend to focus on particular areas or known processes. Auditors are in a constant quest of trying to answer the questions such as; did the work get completed as planned; why was the approved request not completed; and why was there no request for a particular change? A tiny but very important key to meeting many of these challenges is to have tight control on the change management process. We cannot deny that there may be loopholes in approval procedures or in the change management guidelines. Also, reporting and tracking can be a limitation due to various reasons such as; insufficient automation in change management solutions and a lack of capabilities for tracking change history. 

Below listed are few of the areas that require more focus on managing change process: 

• Process Management 
• Approval Matrix 
• Security Measures 
• Unplanned emergency access/changes 

Refer below listed details on the areas of concern:

• Process Management:

A very important question to be answered is to determine a start point; who will initiate the change, how the workflow for the change will be managed? Help desk has been the primary requesting application used on a larger scale by organizations for initiating and tracking changes and this can work well. Organizations are traversing into the market with many other automated process oriented applications as means for tracing the change through its workflow steps.

• Approval Matrix:

One of the most difficult aspects of change management is the change approval matrix (Team Hierarchy). Taking necessary precautions in approving any change is the base of change management process that includes; involving the right people, and evaluating implications to the best of your ability. It is also important to focus on creating a simple to follow process, without too many gates, and not involving too many people so that it becomes inefficient and not leading the staff to look out for ways to avoid the change process itself. Many organizations have established a Change Advisory Board (CAB), which is a cross-section of individuals that meet on a periodic basis, usually weekly, to plan and approve changes that will be needed over the coming week. CAB establishment works well for important changes. A well arched process to set multiple gates for change approval. This would maintain different levels for different approval processes. This gives the organization the freedom to keep lower approval dependencies for smaller changes. The level of approval required depends upon the nature of the business. 

• Security Measures:

One of the crucial focus areas that needs to be focused and managed are the security measures. Unauthorized system access, data visibility and database access are few concerns that need to be governed. Also, maintaining the confidentiality of super-user credentials is highly required. During the Change implementation phase, employees and their respective roles change frequently, and controlling that appropriate access to all types of systems is a tedious task. However, in the given scenario these challenges are dealt as part of administration. Staff training and user guidelines are to be very well framed for meeting the security levels and controlling users from any breach of policies.

• Unplanned emergency access/changes:

Major tripping areas in a change management process is determining how to deal with unauthorized and unplanned emergency changes. The 2 major concerns in resolving this issue; difficulty in collating and documenting the change that has already taken place and resistant that the staff members portray to the change management process itself. 

Unplanned emergency cases will always be part of any organizational process that will also require staff to work outside of the formal process to address a problem situation. Similarly, a decent number of staff members will also take the decision that the change management process does not apply to them. Basic considerations are; how will one document this unplanned changes? How will one monitor the staff for failing to comply with the process? The much expected solution is a penalty for failing to operate according to the process that needs to be relatively severe. 

Regardless of the consequence, it is important for the change management process to have in place a continuous evaluation process for this unauthorized and unplanned changes to work towards identification and reduction of these changes. Few companies attempt to handle these changes just prior to an audit. In such cases, it is generally obvious to an auditor that these types of changes are not being managed. A new process of providing a post-change report, can be formally replaced for emergency changes.

Conclusion:

A change management process is the most tedious phase for a new implementation. This process needs well traced plans and motivated leaders to drive the teams towards achieving organizational goals. The major key factors that help in managing change management in an organization and needs to be well thought about are Process Management, Approval Matrix, Security Measures and Unplanned emergency access/changes.

About Author:

Mrudula Palyekar is a consultant in Systems Plus Pvt. Ltd. Within Systems Plus, she actively contributes to the areas of Technology and Information Security. She can be contacted at: mrudula.palyekar@spluspl.com

Requirement Elicitation Techniques

One of the most important tasks in requirement engineering is requirement elicitation. Requirement elicitation is a practice of gathering things that are needed or wanted and are necessary to draw out or bring forth for a system from users, customers, and other stakeholders. This practice is also sometimes referred as “requirement gathering”.

One of the key objectives of business analysis is to ensure that requirements are visible to and are understood by all stakeholders. It is an active effort to extract information from stakeholders and subject matter expert. Also, requirement elicitation is a technique you can apply appropriately during the requirement phase.

Requirement elicitation is important because one can never be sure to get all requirements from the user and customer by just asking them what the system should do OR not do.

Requirement elicitation technique includes:

Brainstorming:

It is a group creativity technique to produce numerous ideas by which efforts are made to find a conclusion for a particular problem by gathering a list of ideas spontaneously contributed by group members.

Ideally, group size must be of 6-8 members. To ensure this technique, one can set a time limit, make the ideas visual, establish ground rules to evaluate and rate the ideas and do not allow criticism and limit the discussion and rating. This technique is productive and highly motivating.

Document Analysis:

This technique is useful when the subject expert is not available. In this technique, information is extracted from an existing documentation. The documentation should be relevant to the study of matter and based on this information one can understand and analyze.

For example:

Business plans, project charters, business rules, contract, statements of work, memos, emails, training material, etc.

Focus Groups:

This technique saves time and cost by bringing out information from a selected group via a moderator. This process is very formal, more structured and usually of 8-12 attendees. A moderator is a skilled person who promotes discussion, ask open questions, engages all members and remains neutral in the discussion.

Interface Analysis:

Interface Analysis is a business analysis elicitation technique that helps to identify interfaces between solutions/applications to determine the requirements for ensuring that the components interact with one another effectively. This clarifies the boundaries of the application by identifying interfacing stakeholders and by defining the inputs and outputs of the interface. Interfaces can be to/ from external applications, to/ from internal applications, to/from external hardware devices. Interface analysis helps in discovering the requirements needed to integrate software into its new environment.

Interviews:

It is a technique where questions can be geared towards uncovering information. This can be formal or informal that should maintain focus on the goals of the interview. This should aim to find information and gaps between the understandings. This technique can be successful depending upon the knowledge of the interviewer and interviewee(s), the experience of the interviewer and his ability to document discussions. 

Observation:

This is a technique to study stakeholder’s work environment by just observing which is beneficial when documenting current or changing processes. An observer can pen down and won’t disturb by asking questions, such an observer is called a passive observer. Whereas, an active observer can communicate when stakeholders are doing their work.

This technique might consume time and also is not able to observe all possible scenario. 

Process Modeling:

Business Process Modeling is an analytic representation or illustration of an organization. 

For example, UML diagram. It helps to understand work with steps, roles, and department.

It is important that one has to structure this representation in a systematic manner so that it is easier to understand otherwise this can become unwieldy and complex.

For better understanding, one can break complex processed into components. 

Prototyping:

In this technique, first the product is manufactured and then can be tested. This helps to understand the gaps and to know what changes can be made. This is very helpful in validating requirements and uncovering gaps.

This represents the user interface with good validation measure.

Also, supports visual learners with great interaction.

Requirement workshops:

Requirement workshops can be defined as an organized and smooth event where carefully selected stakeholders meet to discover, refine, prioritize, validate and discuss requirements. Usually, a skilled facilitator manages workshop sessions. 

Also, such workshops have the potential to reduce product defects and scope creep. It also helps to save time and effort by 10% on an average throughout the SDLC.

How does it work:

Ground rules are set initially.

Participants are put into different teams to get the discussion going with each team representing a mix of interests.

Participants are given a problem statement to discuss objectives to achieve. They even have to identify requirements, review existing requirements and prioritize each of them.

Survey/ Questionnaire:

Ad hoc conversations and surveys are helpful for gathering information quickly from a large group of participants. As free online survey software are easily available and hence, surveys is an inexpensive method to accumulate most of the information from potential end users and customers. Along with selecting stakeholders, a successful survey or questionnaire must have well-chosen participants. Questionnaire proves to be beneficial to address issues clearly for all concerned when a number of participants are large enough. Surveys offer open-ended input or string of finite choices for feedback, depending on the needs of the project. Open-ended surveys are beneficial to discover broader business needs; however, it gets more repressive to analyze with a large number of participants involved. The survey should be more precise and must be unambiguous. It is a good practice for an analyst to request gallantly so that survey participants respond by a reasonable deadline and that they keep any proprietary business information contained within the survey confidential.

Conclusion:

Thus using requirement elicitation techniques proves to be an ad on when it comes to gathering requirements. One must try using such techniques so that the fullest of the requirement gets covered.

About Author:

Rajeshwari Pawar is a consultant in Systems Plus Pvt. Ltd. Within Systems Plus, she actively contributes to the areas of Technology and Information Security. She can be contacted at: rajeshwari.pawar@spluspl.com

COBIT Indicators for Agile Software Development

In this blog, we are going to talk about the different COBIT controls which can be mapped to Agile software development process. After reading this we can determine if Scrum based software development process can be compliant with the auditing criteria as described in COBIT indicators.

First, let’s talk about how Agile came into existence and what is Agile.

Agile: Earlier the industry relied on Waterfall model of SDLC for software development but as time passed by, concerns were raised because the time gap between gathering requirements and delivering the final product was huge. By the time a working model was delivered the client would need more features or the software that was developed would need an upgrade. This led to cancellation of many projects based on the waterfall model. This growing frustration in the industry made a small group of people come together and come up with an alternative to the existing waterfall model. The outcome of this meeting was Agile Manifesto.

The agile manifesto has four foundation values and twelve supporting principles which can be used in any software development project using agile methodology. I will cover this in detail in the next blog.

Agile takes an iterative approach to deliver the software in increments rather than delivering the entire product in one go. It breaks down the projects into bits, prioritizes the bits with customer’s approval and then delivers a shippable product increment in one or two week’s cycle.

There are different methods of Agile software development but in this blog we will be focusing on Scrum Method.

Scrum: Scrum follows an incremental product development approach. It has a repeatable work cycle of around 3-4 weeks (depends on company’s process) to develop a shippable product increment. This work cycle is called as Sprint. Scrum has 3 roles Product Owner, Scrum Master and Scrum Team.

• Product Owner is responsible to explain and prioritize the requirement for each sprint
• Scrum Master’s job is to facilitate the daily scrum meeting and take care of any impediments 
• Scrum Team is the one who actually builds the potentially shippable product increment

Each Scrum usually has the following 5 processes:

1. Backlog Grooming: Product Owner gives an overview of all the user stories required for the developing the product. The stories captured in this meeting form the “Product Backlog”.
2. Sprint Planning: In Sprint Planning the product owner explains each story to the team. The team gives weightage to each story which is known as “Story Point Estimation”. Based on this the team will prepare the task estimates. Scrum Master then prepares the sprint backlog based on the team’s velocity.
3. Daily Scrum (Standup meeting): In this meeting only three things are discussed:
        3.1 What you did yesterday?
        3.2 What are you going to do today?
        3.3 What are the impediments you are facing?
4. Sprint Review: In this meeting the team reviews the completed work and the work which was not completed as per the plan. The team also gives a demo of completed work to the stakeholders, this process is also called as “show and tell”.
5. Sprint Retrospective: The team meets at the end of each sprint to discuss the pros and cons of the sprint and what should be changed to improve the efficiency of work.

Now let’s see what is COBIT and which different COBIT indicators will make Scrum Methodology of Agile Software development compliant with auditing criteria.

COBIT: Control Objectives for Information and Related Technologies (COBIT) is an IT governance framework created by the Information Systems Audit and Controls Association (ISACA). COBIT focuses on IT controls which is useful for IT Management, users and auditors. COBIT 4.1 has 34 high level process in 4 process domains with 210 control objectives. 

The 4 process domains are follows:

1. Plan and Organize
2. Acquire and Implement
3. Deliver and Support
4. Monitor and Evaluate

In this blog I am going to list down the indicators of COBIT process which will help us in assessing the software development process using Scrum methodology. The selection of process and its indicators are based on the auditing guidelines for SDLC. The below table has the list of COBIT process and indicators.

COBIT Process	COBIT Indicators
PO7 Manage IT Human Resources	PO7.2 Personnel Competencies
	PO7.3 Staffing of Roles
PO8 Manage Quality	PO8.2 IT Standards and Quality Practices
	PO8.3 Development and Acquisition Standards
PO10 Manage Projects	PO10.1 Program Management Framework
	PO10.9 Project Risk Management
	PO10.10 Project Quality Plan
	PO10.11 Project Change Control
	PO10.13 Project Performance Measurement, Reporting and Monitoring
	PO10.14 Project Closure
AI1 Identify Automated Solutions	AI1.1 Define and Maintain Business Functional and Technical Requirements
	AI1.3 Feasibility and Alternate Course of Action
AI6 Manage Changes	AI6.1 Change Standards and Procedures
AI7 Install and Accredit Solutions and Changes	AI7.1 Training
	AI7.2 Test Plan
	AI7.5 System and Data Conversion
	AI7.8 Promotion to Production
DS5 Ensure Systems Security	DS5.2 IT Security Plan
	DS5.3 Identity Management

Conclusion: This blog helps us in identifying different indicators of COBIT process which can be mapped to software development process using Scrum methodology. Thus, with the help of these COBIT indicators we can measure the performance of our process and also understand if our process is compliant with the information systems auditing criteria.

About Author:

Akash Poojary is a consultant in Systems Plus Pvt. Ltd. Within Systems Plus, he actively contributes to the areas of Technology and Information Security. He can be contacted at: akash.poojary@spluspl.com

BA’s Preparation for Go-Live

Project Go-Live phase refers to the development of a project, where the goals of the project are accomplished, so the project is ready for further utilization and maintenance. Deployment is another name of the project Go-Live phase. 

Though we had few failed attempts prior due to fair implementation planning and inadequate analysis, we have come up with some more advancements to Go-Live. Once we have completed all implementation milestones, it is an ending phase that embraces the timeframe between project completion and handover. 

The ultimate desire of all the preparations, stress and potential risks in the accomplishment resides in the submission and Delivery of the project during Go-Live. 

Few checks and remediation follow: 

• Proper Communication with the Stakeholder:

Communication is one key element which has to be applied effectively throughout a project’s lifecycle from the beginning until the end. One should know to find the best out of all known groups to find the unknown groups. The person or group who are not received any of the communication through the course of a project will miss the valuable links that need to be addressed. To avoid such situations make sure a document is prepared to explain the Synopsis or Environment of the project and circulated to all stakeholders. Every stakeholder or product owner must be aware of the Go-Live procedures and Go-Live date. So any issues or concerns related to the product must resolve early. This also requires a POC (Point of Contact) for any such concerns to be addressed. 

• Product Testing: 

Testing is most important for any software product to maintain for quality assurance. There is a number of testing perform throughout the product development lifecycle. But for Go-Live perspective, UAT is most important. 

User acceptance testing (UAT) is the last phase of the software testing process. During UAT, actual software users/product owner test the software to make sure it can handle required tasks in real-world scenarios, according to specifications. UAT is one of the critical software project procedures that must occur before newly developed software is Go-Live. The main purpose of this testing is to validate the end to end business flow. This testing usually happens at the client location which is also known as Beta Testing. 

Following are the entry criteria for User Acceptance Testing: 

• Business Requirements must be available. 
• Application Code should be fully developed 
• Unit Testing, Integration Testing & System Testing should be completed 
• No Showstoppers, High, Medium defects in System Integration Test Phase  
• Regression Testing should be completed with no major defects 
• All the reported defects should be fixed and tested before UAT 
• UAT Environment must be ready 
• Sign off mail or communication from System Testing Team that the system is ready for UAT execution 

• Dry Run:

Dry run involves the construction and evaluation of multi pre-production versions of the product. Early prototypes are usually built with production-intent parts. Means the parts with the same configuration and design as intended for the production version of the product but not necessarily fabricated with actual process to be used in production. 

Typically the terms “Dry run” means a full-scale execution of all tasks involved to extract data from legacy systems, perform any kind of data conversion and fully validate the results. Validation testing of the finished product must be based on testing standard release criteria and in process testing criteria. 

• Roll Back Plan: 

Always be prepare for the worst condition and in Go-Live something went wrong then rollback is the best option. We may face a number of issues in Go-Live like functionality not working, data is not coming properly or some UI issues and if it’s critical and will tack more time to resolve, so in this kind of situation we may need to go back for an older version. A rollback script is supposed to return you to a previous point in time. 

• Post Go Live support:

The purpose of this phase is to move from a project-oriented environment to a live production operation environment. It involves Production support, monitoring, system transactions and optimizing overall system performance. 

Key Participants 

· Project Owner 

· Project Manager 

· Functional/Technical Lead(s) 

· Support/Maintenance Group 

Customer’s success is a big piece of the pie. Will have a direct contact with the customers helping them to get the most out of the product developed. Providing quick, thoughtful and knowledgeable support has made product champions out of even the toughest customers. 

To provide end user support which is critical for a project after Go-Live is very important that the key participants should have set up a Go-Support team which takes care of amendments for the next phase of deployment. 

• Conclusion: 

Before Go-Live must pass through all checkpoints to make sure for easy Go-Live. And must be ready with a plan for the worst condition as well.

About Author:

Niraj Patil is a consultant in Systems Plus Pvt. Ltd. Within Systems Plus, he actively contributes to the areas of Technology and Information Security. He can be contacted at:niraj.patil@spluspl.com

Importance of Training in App Support

What is Application Support?

An Application Support is a process where resources are intended to provide the Customer or end user with information and support related to a company's products and services. Their primary responsibility is catering incidents and requests received from end-users, investigating these and either responding the end user with a solution or escalating it to the other teams that can resolve it. The purpose of an Application Support team is usually to troubleshoot problems, provide guidance, and resolve tickets raised by Customer or end user for the software /services being used by them. Companies usually provide Application Support to their customers through various channels like toll-free numbers, websites, instant messaging or email. There are also in-house Application Support designed to provide assistance to employees.

So it becomes necessary that the Application Support Team is trained in the Domain in which they need to provide assistance. Such kind of training depends upon the structure of the company, the Application Support is working with, like Service Based or a Product Based company. 

In Service Based Companies, they tend to have proper trainings scheduled before a resource is On-Boarded on the project. The primary reason behind structured protocol for training application support resource is that, the cost is billed to the client by the Service providing Company so that proper service is provided to the respective client. 

But when it comes to Product Based Companies, they usually have their in-house Application Support team to troubleshoot problems, provide guidance and resolve tickets raised by Customer or end user. The product based company develops new features month by month and release them to the Customer or end user. Customer or end user try to use these new features and usually don’t understand how to use it and get confused or encounter error while using the same. As a result, they reach out to Application Support team for assistance, expecting that their issue / query will be resolved instantaneously (assuming that the Application Support team is aware of the newly released features and can resolve their issue). However if unfortunately, the Application Support team hasn’t received any training on the functionality / feature which was released to Customer or end user, it results in a delayed / incorrect response to the Customer or end user. This directly impacts the face value of the product due to delayed support provided to the Customer or end user. This situation can be avoided if proper training plan and process is in place.

There are various areas listed below in which an Application Support team should be trained:

Communication skills:

This is the backbone of Application support which is missed in most of the cases or taken for granted. In order to understand an issue correctly and provide appropriate response which the requester understands easily, all the Application support executives should be thoroughly trained on written and oral communication. This can include various aspects like, listening skills, decent command over the primary language used for communication, usage of appropriate words and written communication with respect to grammar. To achieve desired results, periodic training should be scheduled apart from the base training that is conducted during on-boarding. Ideally Soft Skills trainer should be hired to impart such training. Periodic tests (Verbal and written) should be conducted to make sure there was some value addition done by the training.

Domain training:

This is another critical factor essential for providing efficient and perfect application support. In order to provide accurate solution as quickly as possible domain training is very important. This can be executed by proper planning, creating training material if required, deciding the time that would require an average individual to understand the application well enough to resolve queries in an optimum time, preparing test material to check if the respective executive have understood what was taught and last but not the least periodic trainings on the new features or enhancements that are developed and deployed.

Team building training:

This is another important aspect of a successful application support training. This is vital not only for application support but any group of people who have to work together. Team building training helps an individual to be a good team player, to learn to back you team members in emergency, efficient transfer of knowledge within the team and last but not the least trust. This factors can be achieved by conducting team building workshops once a quarter, team lunch and team outings. This helps the team to get together which in turn will help in achieving above mentioned objectives pretty easily.

Conclusion:

Thus, it can be concluded that proper Industry training specifically covering above types should be given to the Application Support Team so that they can help the Customer or end user whenever an issue / request is raised. This not only helps the customer or end user, it helps the App Support Team to understand the business process thoroughly and are aware of the development happening in the company, which increases their interest to grasp the knowledge and increases productivity and quality of services and products

About Author:

Amol Bhembre is a consultant in Systems Plus Pvt. Ltd. Within Systems Plus, he actively contributes to the areas of Technology and Information Security. He can be contacted at: amol.b@spluspl.com

An Introduction to PCI DSS for Beginners

PCI DSS stands for Payment Card Industry Data Security Standard. PCI DSS is a set of industry standard mandatory requirements, which are used to evaluate the security levels of businesses that accept, process, store, and transmit cardholder data or sensitive authentication data pertaining to credit cards. PCI DSS aids merchants, service providers and financial institutions to understand and implement standards for ongoing technology and processes that protect the payment system from security breach and theft of cardholder data and different security policies. PCI DSS standards are mandatory for entities that accept credit cards (known as a merchant) or entities that are directly involved in processing, storing or transmitting of cardholder data to ensure that the cardholder data is protected, on behalf of businesses (known as service providers). PCI DSS is structured in a way to protect sensitive cardholder data by ensuring that the information that is accessed has sufficient controls and protection around its usage.

This article deals with introducing readers to the world of PCI DSS from information perspective. Described below are some of the important terminologies necessary to be aware of; in order to understand the 12 requirements of PCI DSS and shall be useful in understanding the details of these requirements in the upcoming blogs.

Terminologies Involved in PCI DSS:

• Cardholder – A cardholder is any customer who is authorized to use a payment card. 
• Cardholder Data – Cardholder data also denoted as CHD or CD refers to the data contained on a consumer’s payment. It is inclusive of two elements viz. Cardholder data element and Sensitive Authentication Data (SAD).
• Cardholder data elements include Primary Account Number (PAN), cardholder name and expiration date
• Sensitive Authentication Data (SAD) includes data on Magnetic Stripe, Personal Identification Number (PIN) and Card Validation Code (CVC)
• Card Verification Code – Card Validation Code (CVC) also referred to as Card Verification Value is a SAD element that uses secure cryptography to protect the integrity of data stored on the magnetic stripe and reveals forgery.
• Cardholder Data Environment – Cardholder Data Environment (CDE) refers to any person, technology or process that stores, processes and transmits cardholder data or sensitive authentication data.
• Cross - Site Request Forgery – Cross - Site Request Forgery (CSRF) is a vulnerability that is created because of coding techniques which are insecure, that allow for the execution of unwanted actions through an authenticated session.
• Cryptography – Cryptography is a method of encrypting or storing data in a manner, such that only those who are intended to decrypt the same can read it and process it.
• Cryptographic Keys – Cryptographic keys are plain texts transformed into ciphertexts by using a cryptographic algorithm. It ensures the security of the message encrypted in the key created. It allows secure communication and maintains the confidentiality of the data.

PCI DSS Requirements:

The twelve requirements of PCI DSS are categorized into six main sections as below:

• Building and maintain a secure network systems
• Install and maintain a firewall configuration to protect cardholder data
• Do not use vendor-supplied defaults for system passwords and other security parameters
• Protecting cardholder data
• Protect stored cardholder data
• Encrypt transmission of cardholder data across open, public networks
• Maintaining a programme to manage and address vulnerabilities
• Use and regularly update anti-virus software or programs
• Develop and maintain secure systems and applications
• Implementing strong access control measures to restrict access to cardholder data
• Restrict access to cardholder data by business need to know
• Assign a unique ID to each person with computer access
• Restrict physical access to cardholder data
• Maintaining audit logs, monitoring and testing security of network and system components
• Track and monitor all access to network resources and cardholder data
• Regularly test security systems and processes
• Developing and maintaining information security policies
• Maintain a policy that addresses information security for all personnel

Conclusion:

The implementation and compliance of PCI DSS is vital for entities dealing with financial transactions and security of such e - commerce payments. Implementing the PCI DSS is not only a mandate for such organisations but also helps in ensuring that the inflow and outflow of CHD and SAD remains protected and confidential.

About Author:

Devika Vaghela is a consultant in Systems Plus Pvt. Ltd. Within Systems Plus, she actively contributes to the areas of Technology and Information Security. She can be contacted at: devika.vaghela@spluspl.com