For those companies challenged with understanding where and what compliance attributes Winshuttle offers when deployed.

1. October 2014 Winshuttle
Products
Overview
For regulatory compliant
deployments
October 2014
CJJ & RT

2. 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

3. 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.

4. 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 support@winshuttle.com 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

5. 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.

6. 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.

7. 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.

8. 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.

9. 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.

10. 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

11. 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

12. 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

13. 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.

14. 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

15. 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

16. 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.

17. 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

18. 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

19. 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

20. Page | 19
Standard Auditing Options in Central/Foundation
Log Management in Central/Foundation

21. 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

22. 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.

23. 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.

24. 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.

25. 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

26. 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