Regulatory compliance with winshuttle products v7 1docx (5)

October 2014

Winshuttle Products Overview For regulatory compliant

deployments

October 2014 CJJ & RT

Page | 1

Contents

Regulatory compliance with Winshuttle products .........................................................................................2

Compliance and the Winshuttle context ....................................................................................................2

Common Questions ....................................................................................................................................3

A Compliance Overview for the US Food and Drug Administration ...........................................................4

Winshuttle Products .......................................................................................................................................5

How Winshuttle software is to be used .....................................................................................................5

Product delivery and licensing approaches ................................................................................................6

Electronic Records ......................................................................................................................................6

Electronic Signatures ..................................................................................................................................6

Minimum Criteria for CFR compliance testing ................................................................................................7

User identification ......................................................................................................................................7

Approved users only .................................................................................................................................13

Versioning within the product ..................................................................................................................15

Electronic Signature ..................................................................................................................................15

Approval Repudiation ...............................................................................................................................16

Verification and Validation .......................................................................................................................18

Winshuttle Software Development ..............................................................................................................20

The Agile process – Development and Quality Assurance .......................................................................20

Team Structures........................................................................................................................................20

Releases and Release Planning .................................................................................................................20

Requirements specifications.....................................................................................................................21

Development – design, code reviews and unit testing.............................................................................21

Change Management ...............................................................................................................................21

Quality procedures/System ......................................................................................................................23

Referring regulations for 21 CFR ...................................................................................................................25

Page | 2

Regulatory compliance with Winshuttle products

Compliance and the Winshuttle context Winshuttle products are used in a variety of business settings for the automation of many functionally

different data management activities.

Often Winshuttle is not the only system in use and is simply leveraged for the benefits associated with

forms, workflow and tight integration with systems of record.

The rationale for selection and deployment of Winshuttle products is often made with a desire to

implement improvements in business processes through automation and automation with workflow and

improved process transparency.

Winshuttle technology can be deployed as a key decision making component in the end-to-end process

for data management and as such maybe considered a key

source of information for audit and compliance review.

For many scenarios requiring a compliance audit or a

compliance review simple tests can be done against the

technology and system implemented.

What, precisely, is examined in a solution compliance audit

will vary depending upon the industry and nature of the

business, what kind of data is being handled and if

sensitive data is being stored or transmitted.

Compliance and audits Sarbanes Oxley compliance requirements mean that any

electronic systems must have established internal controls

and procedures for financial record keeping and reporting

to reduce the possibility of corporate fraud. The technology that is in use must be reinforced and

configured to maintain and demonstrate compliance in the event of an audit.

Healthcare providers that store or transmit e-health records, like personal health information, are subject

to HIPAA requirements. Pharmaceutical and medical device manufacturers are expected to comply with

various regulations like those produced by the FDA to ensure that manufacturing and quality control

processes are not putting the public at risk.

In each case, the organization must be able to demonstrate compliance by producing an audit trail and

proof of system controls and behaviour.

Auditors will generally ask very specific and targeted questions over the course of an audit about how

things are used, managed and work. These may include what users were added and when, how they are

tracked and approved and who has left the company, whether user IDs were revoked and which IT

administrators have access to which critical systems.

IT often prepares for compliance audits using event log managers and clear and robust change

management approaches to track and document authentication and controls in IT systems.

Failure to meet the expectations of audits can be expensive in terms of sanctions or fines.

There will be relevant information here for audits in the context of SOX, HIPAA and other compliance

requirements.

The objective of this document

is to primarily focus on aspects

associated with Food and Drug

Administration compliance

and the general audit

compliance questions that

often arise with respect to

electronic record keeping and

electronic signatures.

Page | 3

Common Questions Customers and prospects periodically evaluate Winshuttle products for suitability according to a number

of criteria. There can be many different reasons for the evaluation. Evaluations are usually undertaken

from a Quality Management, Compliance Assurance, Audit & Risk, Information Technology Architecture

or Procurement point of view.

Questions may come in form of electronic and paper forms, questionnaires, audits, requests for

proposals, information or quotations (RFI, RFP, RFQ) or simple emails as a part of the normal cycle of

doing business. Part of the objective of this document is to provide answers to some of the questions that

arise as part of a review of Winshuttle product suitability for regulated environments

Certifications Common questions that are asked with respect to Winshuttle products revolve around Winshuttle

Product certifications. Which products are certified with which versions of systems?

As a technology partner of Microsoft, SAP, Oracle and Salesforce, the levels of rigor and certification vary

with each vendor and depend heavily on the objective of the various products.

Winshuttle maintains an ongoing relationship with each of these and other vendors and aims to test and

certify products with each major release in order to maintain compatibility and reassure customers

regarding suitability and correct functioning with specific Winshuttle and target system releases.

Certification testing typically requires either working with the partner certification organizations or

demonstrating compatibility through exhaustive automated testing. Both methods are used.

Details of certifications are usually provided on request by contacting [email protected] but

additional information is available at:

https://support.winshuttle.com/hc/en-us/articles/200125959-Winshuttle-Product-Certifications

Software certifications representative a first step in assuring compatibility. Real world deployment

however provides the best evidence of suitability and compatibility of solutions. Customers and

prospects are encouraged to deploy current versions in ‘like production’ environments early in the

product evaluation cycle in order to identify any possible issues.

Where audit is felt to be a key aspect of solution deployment ‘proofs’ should be tested frequently and

consistently especially where they are only possible when auditing in the system is enabled – this is

particularly important when SharePoint is part of the installation stack.

https://support.winshuttle.com/hc/en-us/articles/200333814-CENTRAL-SharePoint-Auditing

Particular care should be taken when solutions make use of a combination of technologies (e.g.: VB

Macros, VBA Code, Java script, .NET code, ABAP, APEX, PL/SQL, batch files, web services etc.) over and

above the ‘low code’ technology stack that Winshuttle solutions represent on Microsoft platforms.

Security, authorizations, permissions In addition to these varying combinations of technology, security authorizations and permissions in

various systems also represent an area of important focus for the use of Winshuttle products.

Performance and appropriate functioning of certain scenarios may be impaired or behave unexpectedly if

security, permissions and authorizations are not considered appropriately.

Further information on Security and permissions is for each product according to form and purpose

however some common requirements and information are defined at:

https://support.winshuttle.com/hc/en-us/articles/200230100-Transaction-Required-SAP-Authorizations https://support.winshuttle.com/hc/en-us/articles/200574585-Winshuttle-Function-Module https://support.winshuttle.com/hc/en-us/article_attachments/200418024/WS_SupportPack24Issue.pdf

Page | 4

A Compliance Overview for the US Food and Drug Administration The regulations outlined in 21 CFR Part 11 set the ground rules for automated record keeping systems for

organizations subject to the regulations of the FDA.

By affirming that electronic records and signatures are equally as legitimate as paper records and

handwritten signatures, Part 11 gives companies the opportunity to automate and streamline

manufacturing and quality processes without the additional costs and administration efforts of managing,

storing and filing paper and manual records.

The objective of this document then is to assist organizations in understanding how Winshuttle products

assist in meeting and maintaining 21 CFR Part 11 compliance.

While this document focuses particularly on 21 CFR Part 11 compliance it will have broader relevance to

other regulatory requirements also.

In your assessment of 21 CFR Part 11 compliance consider the role that Winshuttle technology plays or

will play in the end-to-end record keeping process.

In many instances there is no requirement for Winshuttle to be explicitly 21 CFR Part 11 compliant

because it is not the designated System of Record (SOR) and contains only a part of all pertinent and

relevant information with respect to a given process.

Understanding the way in which you have deployed or plan to deploy Winshuttle technology will assist

you in determining the level to which you need to examine Winshuttle Software for 21 CFR Part 11

compliance.

Page | 5

Winshuttle Products Winshuttle Studio - a suite of desktop applications that enable non-technical and technical users to build

data management and process automation solutions for use with Microsoft SharePoint®, Microsoft

Office® and Web Forms. http://www.winshuttle.com/products/studio/

Winshuttle Central – a governance, compliance and collaboration platform built on SharePoint® within

the corporate network that enables users and IT to control and manage their use of data management

and process automations built with the Winshuttle Studio suite.

http://www.winshuttle.com/products/central/

Winshuttle Connect – a cloud license management platform that enables license administrators to

control and manage users of Winshuttle Studio suite. http://www.winshuttle.com/products/connect/

Winshuttle Foundation – a on premise governance, compliance and advanced collaboration platform

built on SharePoint® that enables users and IT to control and manage the use of templates, web forms,

custom workflows and various automation objects used by business for data management activities.

http://www.winshuttle.com/products/foundation/

How Winshuttle software is to be used It should be clear that Winshuttle products can be deployed in a variety of ways across a wide variety of

industry segments and industry solutions.

As such Winshuttle products should be considered as a low code scalable platform for business process

automation but with the ability to simultaneously sustain tight integration with systems of record like

SAP.

In most instances the system of record that the Winshuttle platform components interact with, are SAP

ERP systems however there are occasions when Winshuttle products are used with other types of

systems also such as SAP CRM, Salesforce CRM Sales and Service and Oracle EBS.

Winshuttle products support a variety of modes of use for the extraction, creation and maintenance of

not only Master Data but also transactional and reference data from systems of record.

Winshuttle products are used to expose application functionality in the target system for data creation

and update. Winshuttle does this in different ways with different types of system of record.

In SAP systems this is achieved by way of transaction recordings which have characteristics similar to an

application screen scraper. Another approach that can be used, reveals application programming

interfaces, accesses web services or makes business application logic or data structures available for use.

The Winshuttle platform controls the logical relationship between applications like Microsoft Excel and

web forms and the system of record.

The ability to manipulate systems of record is normally bound by the limitations and capabilities of a

given user’s authenticated credentials on a given target system and as such this should always be

considered as an important aspect of how the platform can be best leveraged for process automation.

Where Winshuttle solutions are used as a staging platform for the gathering of data prior to creation or

for the maintenance of data on the target system of record certain capabilities are inherited from the

Microsoft platforms on which Winshuttle products depend. This dependency determines the way data is

made available for review, manipulation or general access.

For processes subject to compliance scrutiny, appropriately and properly configured Microsoft

technology will usually be sufficiently compliant due to the inherent dependencies the Winshuttle

platform has on Microsoft technologies.

Page | 6

Product delivery and licensing approaches Winshuttle products can be licenses in several different ways

1. Standalone Desktop

2. Desktop deployment Centrally Managed with out-of-the box processes

3. Desktop or Server-based deployment Centrally Managed with fully customizable processes

(Winshuttle Foundation)

a. Excel data based processes

b. Web forms based processes

c. SOAP Web Services

Electronic Records For the purposes of compliance an electronic record is considered as a record required for a Quality or

Production purpose that is held electronically. Examples of Electronic Records include, but are not

limited to Customer and Vendor records, Material Master Records, Bills of Material, Purchase Orders,

Purchase Requisitions, Sales Orders, Accounting Documents, Personnel Records, Manufacturing Batch

Records, Training Records, and Customer Complaint or Service Records etc.

If Winshuttle is to be used for the maintenance of data associated with any or all business activities that

are subject to Electronic Record management then it should be determined whether Winshuttle

technology is used as the sole source of that electronic record.

Often Winshuttle technology is considered as merely as a complementary technology for the actual

designated system of record e.g.: SAP. In such instances, the target system is considered the proper

source for proof of authorized use.

Winshuttle applications can be used for the recording or staging or maintenance of a great many

different types of data in Excel, Access, text files of varying types, as well as Microsoft SharePoint.

Electronic Signatures Electronic signatures are comprised of two parts, a publically known identifier and the passcode or key

used to verify that the identifier is being validly applied.

The first part is ordinarily the username used to identify the user uniquely and trace their job role and

training record to verify that their authority level and competency are appropriate to sign in a given job

role.

The second part can be biometric data but could just as easily be a single or multi factor password or key.

Winshuttle products require electronic signatures in order to be used, anonymous use is not possible.

Use of the platform by way of a generic anonymous user identifier and a shared password is ordinarily a

license violation and constitutes product misuse.

Anonymous users creating/changing records may also be a violation of an internal control and audit

policy also.

Page | 7

Minimum Criteria for CFR compliance testing

User identification

Summary of requirement 21 CFR Part 11 requires an assurance of the authenticity of electronic records. To maintain compliance,

system administrators need to have a system that offers the ability to delineate user permissions for

every document storage library in the system. The system must also be able to generate an audit trail for

any captured document.

How the requirement is met Depending on the deployment approach this requirement is met in different ways. Deployment of

products can be undertaken standalone, with Winshuttle Central or with Winshuttle Foundation

according to the requirements of the business.

In all cases, the System of Record is considered to be the absolute proof of authorized use.

System of Record becomes absolute proof of authorized use All systems of record require a user name and password even if Single Sign On or tokens are provided or

inherited by the Winshuttle application.

An example of a token includes, but is not limited to the use of a Winshuttle Auto-Logon Files (ALF) which

contain user names and passwords defined by users for use with various systems of record. The ALF’s can

be used for unattended or scheduled execution of automations. The ALF is encrypted using the AES-128

standard.

Standard SAP (SOR) credential challenge

Auditing of data activities needs to revert to the system of record, although there will be some indication

from the Winshuttle client as to what activities were performed against which systems on which

occasions and with which credentials.

Page | 8

Standalone Desktop Deployment In situations where Winshuttle is deployed standalone, using either Winshuttle Connect or Winshuttle

LMS as the licensing mechanism, there is no workflow process. However, whenever the user uses the

Winshuttle software, they are required to enter their email address and password for the licensing

system.

Winshuttle’s approach to electronic signatures is such that every user needs to be appropriately

identified and their ability to use Winshuttle software is identified by the provision of a unique user

identifier together with a password.

Standard Winshuttle Connect credential challenge

It is however possible to activate the license checkout in such a way that the credentials are remembered

until such time as they are reset – this a usability feature.

When Winshuttle products are used to create or maintain data in systems of record and the Winshuttle

products are licensed in standalone mode then the system of record becomes the de facto proof of

authority.

This user identifier is used to track product usage as well as verify that the user is authorised to use the

product.

Page | 9

Standard Winshuttle client usage log

Users also have the ability to access a history of their use of the application in Winshuttle Connect

Standard browser user name and password challenge for Connect

Licensing view of a given user in Connect

Page | 10

Central Deployment Where Winshuttle is deployed in a Workgroup it is recommended to incorporate the Winshuttle Central

governance and compliance platform. Users are authenticated against the Central system to determine

the following attributes:

License Type

Role

Applicable policies and restrictions

Once the user has had their credentials verified, their license type checked out and their role verified,

they can begin to either create or leverage automation objects. The ability to create automation objects

is dependent on license and role as well as policies and restrictions.

If a user leverages an automation object, they may only use this against a system defined in the Central

configuration.

Winshuttle Central further restricts the use of unapproved automation objects against designated

‘Production’ systems of record as an additional precaution against developer users inadvertently applying

data and automation objects against productive systems without approval.

Usage policies can be selected in Central to determine what approach is the most acceptable to the

business for use, administrators have the option of simplifying the creation of automation objects and

making automation objects not subject to approval workflows if desired.

License Management view in Central/Foundation

Page | 11

Foundation Deployment Where Winshuttle is deployed in an Enterprise scenario, Winshuttle Central governance and compliance

platform become prerequisite, users are authenticated against the Central system to determine the

following attributes:

• License Type

• People and Groups

• Applicable policies and restrictions

Once the user has had their credentials verified they inherit their permissions, role and associated

licenses according to Central system assignments. Users can begin to either create or leverage

automation objects including scripts, templates and forms.

The ability to create automation objects is dependent on license and role as well as policies and

restrictions.

SharePoint permissions restrict areas of the Winshuttle Foundation platform that a given user can access

– as such these permissions are fully configurable by a suitably competent SharePoint and Foundation

administrator.

If a user leverages an automation object, they may only use this against a system defined in the Central

configuration.

Winshuttle Central further restricts the use of unapproved automation objects against designated

‘Production’ systems of record as an additional precaution against developer users inadvertently applying

data and automation objects against productive systems without approval.

Usage policies can be selected in Central to determine what approach is the most acceptable to the

business for use, administrators have the option of simplifying the creation of automation objects and

making automation objects not subject to approval workflows if desired.

Standard People and Groups view in Central/Foundation

Page | 12

Differentiated Users Winshuttle products support three types of users: authors, runners and reviewers

As implied by the titles of these three types of users, suitable role assignments and licenses need to be

also assigned to these users.

Users that are not using Winshuttle desktop applications such as Studio, Transaction, Runner etc. and

who only use web based forms would be assigned platform licenses appropriate to the way that they use

the applications. For simplicity purposes these can be considered as:

• Professional – Ability to use desktop clients for mass and single record data scenarios –

these usually require the additional use of Microsoft Excel, Microsoft Access etc.

• Standard – ability to start, participate or conclude a process typically associated with single

records – ordinarily these users would primarily use forms based processes only.

While users can be assigned multiple licenses, ordinarily only one license type is typically assigned.

Licenses are assigned based on user identifiers.

Role of the System of Record

Record Created/Maintained by Proxy There are rare occasions when it is considered appropriate for a process to leverage a system or generic

account for the maintenance of data in the System of Record.

Under such circumstances the ability to discern the originating, approving and final action user can only

be determined by referring to the Winshuttle platform logs because a system or generic automation

user account has been used.

Records and documents created or changed in the Winshuttle platform are changed or created using

identifiable credentials – in most instances this is the Windows Active Directory credentials of the user.

Logs can be viewed in the log associated with the forms based process or licensed product that was used

for the data CRUD* activity.

Records Created/Maintained Explicitly Users cannot intercept workflow processes for which they are not designate.

Designation can be undertaken explicitly or systematically. When undertaken explicitly this is done by

direct manual selection. Systematic assignment is done by rules within the workflow engine where auto

assignment occurs based on group assignments or the fixing of document, system or credential

identifiers. Triggering events are timers or process events as defined in the workflow.

In some circumstances even with workflow task assignment, the approval or action decision can be

enhanced further with an authentication challenge in addition to the platform authentication.

Where a proxy is not used, an encrypted token [containing system stored credentials] is passed by the

Central system to the Workflow and Server engine to accompany the request for a CRUD* action on the

system of record. When a proxy is not used, the user who finalized the activity has their credential

attached to the event in the system of record.

Evidence of approval or commencement of the data change or create process can be obtained from the

logs of the Winshuttle Foundation platform in the Forms and Workflow libraries.

*SAP systems do not support full CRUD or full CRUD logging. From an audit perspective evidence of data

extractions in particular may require scrutiny of the Winshuttle Foundation platform logs only. For the

highest possible efficacy in systems logging, auditing should be enabled on all systems of record including

SharePoint.

Page | 13

Inherited user permissions for libraries, lists, folders and documents Windows SharePoint Services 3.0 provides the ability to manage permissions on individual lists and

libraries, and on individual folders, documents, and list items within those lists and libraries.

Any users with the Manage Permissions permission on a particular securable object, such as a list, library,

folder within a list or library, document, or list item can manage permissions on that particular securable

object.

By default, Site Owners have the Manage Permissions permission. Any user with the Full Control

permission level on a particular securable object can also manage permissions on that securable object.

Winshuttle Central and Winshuttle Foundation Workflow libraries, lists, folders and documents comply

with these SharePoint Services controls

Approved users only

Summary of requirement According to 21 CFR Part 11, all users who have been approved to use the electronic system must be

sufficiently trained to perform their assigned duties. A system that incorporates automated training

capabilities can provide automatic triggers when an essential quality document is revised in order to

ensure sustained 21 CFR Part 11 compliance. A system with a proven training component should also be

able to automate the follow-ups and escalations of past-due training tasks as well as create audit trails

for all training data.

How the requirement is met Requirements vary from customer to customer however the flexibility of the Winshuttle Foundation

solution supports the implementation of forms and workflow methods to augment business processes

that require an audit trail of approval. Users who are not defined, cannot participate in a process.

Such processes have to be built based on the requirements of the use case and as such a decision as to

whether a participant in a process is approved to participate in that process can be managed using a

variety of external validation processes including but not limited to:

Internally maintained lists of certifications

Externally maintained certification verification services

Externally defined organizational structures

Page | 14

Workflow Example with Training Checks

Winshuttle itself provides training on the use of its products through a variety of mechanisms including,

instructor led sessions, train the trainer, webinars and eLearning however training on specific processes

pertinent to a particular organization is left to organizations to determine and manage for themselves.

Further documentation on Winshuttle Central Administration & SharePoint Security

https://support.winshuttle.com/hc/en-us/articles/200297700-Winshuttle-Central-Administration-and-SharePoint-Security

https://support.winshuttle.com/hc/en-us/articles/200261125-What-Authentication-Model-is-used-

https://support.winshuttle.com/hc/en-us/articles/200230290-How-to-configure-Doublehop-Security

https://support.winshuttle.com/hc/en-us/articles/200248795-CENTRAL-Domain-Groups-Nested-Active-Directory-Groups

Page | 15

Versioning within the product

Summary of requirement Document controls must provide revision controls, change controls, and time-based system

modifications. In these regards, an organization's internal business processes and specific corporate

protocols must be evaluated in order to determine what is needed to formulate an individualized 21 CFR

Part 11 compliance checklist.

How the requirement is met Assuming that people and groups has been appropriately configured, users will inherit all the access

controls appropriate to assignments. Enabling auditing will ensure that all activities are recorded.

By default document library versioning is enabled and is a prerequisite for appropriate use of Winshuttle

products when used with Central and Foundation on the SharePoint platform.

This section should be considered together with the contents of the Microsoft Document:

SharePoint 2013 Configuration Guidance for 21 CFR Part 11 Compliance Revision 1.00 (June 2013)

Electronic Signature

Summary of requirement 21 CFR Part 11 compliance requirements also require that signed electronic records include the following

data: name, date and time of signing, and meaning of signature. An effective electronic system should

provide fields for all such required information to ensure 21 CFR Part 11 compliance as well as for

supplementary information (if such fields are desired for use).

Electronic (and handwritten) signatures must be able to be linked to their corresponding electronic

records. An established electronic system should easily be able to link every signature with a specified

record.

How the requirement is met Electronic signatures should not be confused with digital signatures. By default Winshuttle products are

not provided with a digital signature capability however electronic signature support and adherence is

provided as previously described.

Electronic signatures and handwritten signatures executed to electronic records shall be linked to their

respective electronic records to ensure that the signatures cannot be excised, copied, or otherwise

transferred to falsify an electronic record by ordinary means.

Electronic signature and approval information are stored as part of the audit trail and metadata

associated with documents. The linkage between signature and document is maintained by the

SharePoint server in the database and can be read in the document through document templates.

Electronic signatures are unique to one individual and are not reused by, or reassigned to, anyone else;

this is an inherited capability from the Active Directory user administration.

Note where reference is made to Active Directory , this includes windows integrated (NTLM and

Kerberos) authentication, basic authentication, forms authentication as well as Claims Based

Authentication using SAML 2.0 tokens.

Page | 16

Approval Repudiation

Summary of requirement The potential for a signer to repudiate an approval must be minimized. An automated system meeting

the requirements of the 21 CFR Part 11 checklist should require users to enter two passwords to approve

any type of document collaboration, one password for login and another for approval.

How the requirement is met Approval repudiation is only applicable where Winshuttle Foundation is deployed.

Two Factor Authentication for actions In all other instances two factor authentication exists but this is limited to authenticated use of the

Winshuttle application either within a desktop client or within the Windows Active Directory and then

the secondary authentication against the system of record when some CRUD action is to be performed.

Winshuttle Foundation deployments A number of deployment options are available for the deployment of Winshuttle Foundation for the

interaction with systems of record (SOR).

1. Client interactive sessions for CRUD actions against SOR

2. Unattended ‘auto post’ or ‘auto run’ action against SOR with proxy electronic signature

3. Browser interactive sessions for action against SOR with proxy electronic signature

4. Browser interactive sessions for action against SOR with explicit electronic signature

Client interactive sessions Users that interact with the system of record typically can only perform actions once a submission and

approval process has been completed. The approval process may have one or more approvers and

approval is made explicitly by electronic signature of an appropriately authorized user in the Winshuttle

system. The supply of approval for the action sets a flag against the data object in the Winshuttle system

which makes it possible for the user to perform the action. As a part of this execute action, the user will

be prompted to enter a user name and password for the target SOR. The electronic signature challenge

for the SOR prevents user repudiation of the action.

Unattended Users that choose to have the SOR action execute in unattended mode rely on an execution engine as

part of the technology stack. This execution engine is known as Winshuttle Server and is only available as

part of the Winshuttle Foundation installation set. Winshuttle Server uses a proxy based approach for

execution of action against the SOR, linking the authenticated credential of the executing user with an

encrypted electric signature file stored within the Winshuttle Central infrastructure. The user’s

interaction with the SOR is asynchronous. This option should likely not be used if there are concerns

regarding user repudiation of the action.

Browser session with proxy Users that interact with the SOR in real time or near real time from a browser have the ability to leverage

the encrypted SOR credential to reduce the amount of data required for entry into a given form based

process. This option should likely not be used if there are concerns regarding user repudiation of the

action.

Browser session with credential Users that interact with the SOR in real time or near real time from a browser but who do not wish to

leverage the encrypted SOR credential can expose the entry fields for user name and password for the

SOR within the form. Communication between the form and the Winshuttle Server which acts as the

Page | 17

execution engine with the SOR is undertaken via HTTPS to maximize protection of the electronic

signature. The electronic signature fields for the SOR prevent user repudiation of the action.

Additional options to prevent repudiation An additional option can be enabled for browser based sessions. This option involves the enabling of a

secondary challenge for approval actions. Enabling of this feature can be undertaken irrespective of

whether a SOR is incorporated into the end-to-end business process or not.

As such, when the Winshuttle Foundation environment is used as the SOR for a given end-to-end process

the ability to prevent approval repudiation is possible. Where Winshuttle Foundation is not the SOR, this

capability can also be enabled but may be redundant

Page | 18

Verification and Validation

Summary of requirement The FDA requires that the electronic system must be validated. Implementation of an electronic system

with a proven track record of performance and validation can drastically reduce the time and money a

company devotes to its overall validation efforts. Depending on the company's internal corporate policies

and risk evaluations, validation can be as simple or as thorough as the electronic system will allow.

How the requirement is met The integrity of the end to end system is heavily dependent on configuration.

Configuration should be undertaken with best practices in mind from a practical system administration

perspective, usability and at the same time against the expectations of compliance and auditability.

With SharePoint as a key technology within the Winshuttle Central and Foundation technology stack and

with only Central and Foundation being options for centralized document management and approval

workflows, it is only considered relevant to focus on the electronic records that are housed within the

Central and Foundation systems.

Proof of appropriate record keeping in the Central and Foundation systems is best achieved through

scenario testing however the following customer case studies provide insight into the different kinds of

processes that Winshuttle customers apply to the Central and Foundation platforms.

It is important to again consider where Winshuttle fits into a landscape of workflow approval relative to

some designated system of record, in many instances, Winshuttle technology is not the system of record

and full audit and data analysis of change and create logs are undertaken on the system of record with

Winshuttle Central and Foundation logs providing supplementary information.

In most instances some other system of record is in use such as SAP however there are some occasions

where only the forms and workflow components are in use.

Various audit reports and options are available within the Central component and it is at the discretion of

the business to determine which of these are most important for creation and retention.

Standard Auditing view in Central/Foundation Administration

Page | 19

Standard Auditing Options in Central/Foundation

Log Management in Central/Foundation

Page | 20

Winshuttle Software Development Winshuttle has been producing automation software for use with ERP’s like SAP since 2003. During the

course of this period the methods used for software design and development, change management and

the quality assurance process have evolved to be aligned with the requirements of the business.

Accordingly, because an important part of vendor software evaluation includes software verification and

validation, some critical aspects of the Winshuttle SDLC are described here for informational purposes.

The Agile process – Development and Quality Assurance Winshuttle presently follows an agile software development approach which is iterative and incremental

(evolutionary) performed in a highly collaborative manner with just the right amount of ceremony to

produce high quality software in a cost effective and timely manner which meets the changing needs of

stakeholders.

Team Structures Development teams for a given product are structured in a self-organizing units referred to as PODs. POD

design is a concept that focuses on modularizing work: making units more independent, adaptive,

linkable, and swappable. Teams manage themselves and the software development, QA and Product

managers move to a role where they act as mentors and facilitators.

Managers may spread across multiple PODs.

Releases and Release Planning Release planning is used to filter the product backlog – the backlog is a list of software defects, new

features and product enhancement requests generated by the support, services and product

management organization as well as others.

Plan

• Strawman

• Project plan

Design

• FRD

• Wireframes• Prototype

Build

• TRD Review

• Sprint Demos• Documentation

Pre-Release

• Product Launch checklist and Scorecard

• UAT

• Documentation

• FCS/Beta

Release

• Training

• Webinars

Retrospective

• Lessons Learned

• Action plan• Communicate and track

Page | 21

The contents of a given release plan factor in the desired release dates and the availability of resources to

meet the objectives of the release.

The release planning process involves the Engineering team and the Product Owner negotiating on what

can be reasonably incorporated into a release based on a stack ranking methodology which factors in

priority, impact, value and risk as well as complexity and clarity of understanding as regards the

characteristics of the issue.

The release backlog often comprises architectural changes, theme features, enhancements and bugs.

An initial level of effort estimation is provided to assist in the project planning – this is often considered a

‘T’ Shirt sizing exercise. The output of this process is the prioritized release back log in the form of a

release straw-man and also a project plan.

Items for inclusion in the release may be defined for specific sprints (short defined software development

cycles) but may also remain unassigned until development managers work with the PODs on determine

who would work on particular user stories.

Requirements specifications Before the start of a software development sprint, ‘user stories’ are defined and entered in the issue

tracking system. The requirements are defined in the issue tracking systems within the stories or are

contained with functional requirements documents (FRD).

A user story may comprise one or more sentences in the everyday or business language of the end user

or user of a Winshuttle application. The story captures what a user does or needs to do as part of his or

her job function. User stories are used with agile software development methodologies as the basis for

defining the functions the product must provide, and to facilitate requirements management.

A user story captures the 'who', 'what' and 'why' of a requirement in a simple, concise way, often limited

in detail.

Development – design, code reviews and unit testing All major requirements go through a high level design discussion. The design is documented in the form

of a High Level Design (HLD) document. It is the responsibility of the development manager to make sure

that the overall architecture document is updated based on any design change flowing from changing

requirements. The HLD document also contains references to the impacted areas in the product to

provide more details to the Quality team for regression and scenario testing.

No code is checked in the main branch without a code review.

Code reviews happen at two levels of code reviews – Manager Review and Peer Review.

Unit test coverage is mandatory for any new piece of code. Development teams also have targets to

maintain a minimum threshold value in unit test coverage.

Change Management Changes are reviewed, verified and validated as appropriate and approved before implementation. The

review of design and development changes includes evaluation of the effect of the changes on

constituent parts and product already delivered.

Changes to the versions of the work product are handled to maintain appropriate traceability

between requirements, designs, code, testing specifications, user manuals and, where relevant,

other additional items.

The extent of the traceability is dependent on the complexity of the product and/or release.

Page | 22

After the FCS (First Customer Shipment) release, we consider any request for change from beta

customers or support as a change request.

Change requests are handled in the following steps:

Request is logged by the user in the form of an Improvement, New Feature or Problem and

submitted to Product Owner by way of the issue tracking system.

Analysis is done by the Product Owner and an approximate level of effort to resolve is determined in

consultation with development team to make the change.

If clarification of the issue is required, this is done through the issue tracking system

After discussion a targeted fix version is assigned to the issue. This will indicate when and as part of

which release the issue is planned to be fixed.

Impact analysis is then done to indicate which artifacts should be updated in order to effect this

change. A Task is created and assigned to development team which also enlists the documents that

will be changed by way of the issue tracking system.

Once changes are done and relevant documents are updated, the solution is passed to the Quality

Assurance (QA) team for verification.

After complete verification by the QA team, the build is certified and the fix is incorporated in the

relevant release.

Any changes requested by customers or support in existing features after GA (General Availability)

milestone are taken as a change request by the engineering team.

Post GA release change requests are handled in the following way:

Customers typically contact Winshuttle Level-1 support and raise a support ticket for their issue. This

ticket is logged in our support ticket tracking system.

Level-1 support tries to resolve the issue in case this is mere a configuration issue or in case a

workaround can be provided. If it is resolved then the case is closed at that stage and supporting

information is added to our support knowledgebase. Internal resources that identify issues work

with support to determine whether the issue is configuration or environmental. Support operates

with multiple levels of competency and skill and customer reported issues are escalated within the

support organization accordingly.

If the issue cannot be resolved by support then the issue is escalated in the support tracking system

and the issue is replicated in the issue tracking system used by development.

Within software engineering issues that are escalated are triaged against a variety of criteria. These

include but are not limited to reproducibility, works as designed, bugs, design defects and

enhancements. The product owners work with the engineering escalation team to determine

whether an escalated issue becomes a candidate for the product issue backlog.

Analysis done by Product Owner and approximate level of effort is determined in consultation with

development team to plan for a product change.

After discussion a fix version is assigned to the issue. This will indicate when and as part of which

release will the issue be fixed.

Task is assigned to development team which also enlists the documents that will be changed.

Page | 23

Once changes are done and relevant documents are updated, it is passed to Quality Assurance team

for verification that the change addresses the issue that was raised.

After complete verification by QA, the build is certified and the fix is incorporated in the relevant

release.

Quality procedures/System

Validation and Verification Validation refers to confirmation by examination and provision of objective evidence that the particular

requirements for a specific intended use are fulfilled.

Wherever practicable, validation is completed prior to the final delivery or implementation of the

product. Records of the results of validation and any necessary actions are maintained.

Before demonstrating the product to the customer, the operation of the product is validated in

accordance with its specified intended use, under conditions similar to the application environment, as

may be specified in the contract.

Any differences between the validation environment and the actual application environment, and the

risks associated with such differences, are identified and justified as early in the life cycle as possible, and

recorded accordingly.

Testing is performed for validation of design and development products. The approach and extent of

testing, and the degree of controls on the test environment, test inputs and test outputs may vary

according to the complexity of the product and the risk associated with the use of the product.

Verification is confirmation by examination that specified requirements have been fulfilled. Proof is made

by the provision of objective evidence.

Verification of software is performed in accordance with planned arrangements as per the Quality Plan,

to ensure that the design and development outputs have met the design and development input

requirements.

Verification activities may comprise reviews of design and development output (e.g. by inspections and

walkthroughs), analysis, demonstrations including prototypes, simulations or tests. The verification

results and any further actions are recorded and checked when the actions are completed.

Only verified design and development outputs are demonstrated for acceptance and subsequent use.

Any findings are addressed and resolved, as appropriate.

Test planning Winshuttle aims to bring quality products to their customers and test planning becomes a key part of the

process.

In the POD structure, QA is not differentiated from Development and a code is incomplete if not unit and

QA tested.

This approach calls for closer collaboration between code writers, reviewers and testers. The diagram

below illustrates the different Review and Test activities undertaken during the software development

life cycle.

Page | 24

Requirement traceability Any bugs or issues can be traced back to the requirement they originate from. Every user story has a

testing component/task associated with it. Code check-ins for any enhancement/bug fixes refer back to

the issue tracking number. Test cases are not linked to the corresponding issue tracking number but can

be traced back through the component name.

Development documentation The following types of documents are controlled:

Process documents

Release documents

Product Requirements

Code, Design, Test reports

Standards and related documents

Test plans – Environment, Performance

All documents are held in an electronic form on our internal document management system segregated

by product.

The responsibility for the approval lies with the owner of the product and is done through a combination

of emails/web meetings.

Any changes to the documents are published as a minor version and an approved copy as a major

version.

SharePoint out of the box version control is used to maintain history of changes.

An un-authorized user cannot view or make changes to any of the documents listed above. It is controlled

using SharePoint group/user permissions.

Review

Release Plans

Requirement Specification

Design

Test plans

Test cases

Test results

User Manuals

Downloads Links/Installation

Test

Acceptance

White Box

Structured

System Level

Localization

Performance

Exploratory

Regression

Page | 25

Referring regulations for 21 CFR CFR - Code of Federal Regulations Title 21

http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?CFRPart=11

Guidance for Industry Part 11, Electronic Records; Electronic Signatures — Scope and Application

http://www.fda.gov/downloads/Drugs/GuidanceComplianceRegulatoryInformation/Guidances/

UCM072322.pdf

General Principles of Software Validation; Final Guidance for Industry and FDA Staff

http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/ucm0

85281.htm