Control Register
SD02 | GxP classified Information Systems are validated, and validation status is periodically reviewed | a) GxP-relevant Information Systems are validated to verify fitness for purpose. - Validation follows a QA-approved procedure. b) Validation status of GxP Applications is defined a Validation Master Plan. c) Validation status is periodically reviewed. Review period is 3 years (or risk-based and defined). - GxP Periodic Review Reports are documented and approved by QA eCPL. - GxP Periodic Review Reports summarize fitness for purpose and confirm validation state for intended use. - GxP Periodic Review Reports include a review of application Major incidents (MIM), information security incidents and information risks and confirmation they are appropriately managed.
-- | -- | --
SD03 | System acquisition and design is documented and includes business, security and compliance requirements | a) Business, security and compliance requirements are defined and implemented as part of system acquisition and design. - Design requirements related to data management and eDiscovery are identified and included in the system design (as applicable). b) Requirements for Business Information retention are identified and implemented. - Where technically feasible, systems are set up to automatically delete Business Information and data based on a maximum retention schedule, i.e. as soon as there is no valid (legal, regulatory or business) requirement anymore to keep the data. - For systems that may hold data that could be under Legal Hold, there must be a means to suspend automated deletion where requested by Legal. - Where such deletion cannot be performed in an automated manner, a defined process is put in place to identify and subsequently delete Business Information and data that is past its retention period (and not on Legal Hold). c) Requirements for access control and access management are defined and implemented as part of system development or acquisition. - Requirements for access roles and their permissions are identified (including segregation of duties), and developed or configured accordingly. - Access roles and their permissions are documented. - All accounts created during system development are approved or removed prior to migration to Production. d) The design and development of custom built Systems, and customization of acquired Systems, are appropriately documented. System documentation includes: - Business, security and compliance requirements, and how these were addressed or verified. - System documentation that describes the system installation, administration and operation. - System configuration. - High-level design and detailed design specifications (or as-built specifications). - System parameterization and configuration information. - Source code documentation. - Traceability between requirements and testing. - System documentation follows Good Documentation Practices. e) Where technically feasible, application front-end to back-end encryption is implemented.
SD04 | System interfaces are documented and meet security and monitoring requirements | a) For each system interface, the interconnection characteristics, security requirements, and the nature of the information communicated are documented. b) Interfaced systems which consume the data of the source system, have a classification that allow the processing of the data being accessed or transmitted over the interface. c) For interfaces which transmit Integrity Vital information, data transmissions or interfaces between systems that transfer data which is critical, include controls (e.g. checksums and manual checks) over the completeness and accuracy of transmissions. d) Interfaces are appropriately monitored to ensure the integrity and security of business information.
SD05 | Secure coding practices are followed | a) Secure programming practices are applied in line with best practices (e.g. OWASP).
SD06 | System is tested before operational use | a) System test plans are developed and executed before system are released for operational use. - Unit, integration, system, regression and user acceptance testing is executed in line with the defined test plan. - Security testing confirms that the required security controls are implemented correctly, operating as intended, and meet established security requirements. - Evidence of the execution of the test plan and the results of the testing is maintained. - Issues and flaws identified as part of system testing are resolved prior to release to Production. If not, appropriate handover occurs and issues (and risks) are documented and approved.
SD07 | Migration, conversion and archiving of data is appropriately managed | a) If system data is migrated and/or converted: - An approved data migration or conversion plan exists describing the process of migration and verification. - Evidence for data migration or conversion activities is documented to verify the integrity, accuracy and completeness of data. - The importance and classification of data, along with technical risk of the transformation, define the extent of migration verification. - Completed migration activities are formally documented. b) Archived data is managed to ensure security, retrieval, accessibility and disposal.
SD08 | System transition to operational use is controlled and documented | a) The following processes are implemented prior to operational use: - Change Management. - Configuration Management (if required). - Incident and Problem Management. - Identity and Access Management. - Operational Recovery (if required). - Disaster Recovery (if required). - Backup and Restore Management (if required). - Deviation and CAPA Management (GxP-relevant systems). - Responsibilities for system configuration, management and operation are defined using standard roles. - For GxP-relevant systems these processes should be documented in QA eCPL approved procedures. - For transition to AMS, a Service Transition Plan is created. b) The Development / Delivery Team prepares a Handover Checklist (Service Transition Report or equivalent) which describes: - Knowledge Transfer. - Any post-go-live issues. - Support Organization and SLAs. - System lifecycle deliverables. - Any handover observations and action plan. c) For GxP-relevant systems, the Qualification Report and/or Validation Report is completed and approved by QA eCPL (or delegate). The information System is not used for GxP operational purposes in the Production environment until approved by QA eCPL (or delegate). d) A pCMA is completed to verify technical control implementation prior to operational use.
SD09 | Electronic Privacy Assessment is performed for systems containing personal information | a) An Electronic Privacy Assessment (ePA) is performed for systems containing Sensitive Personal Information, PI-Full or PI-Limited information and data. - Any additional privacy and security design requirements identified are included into the overall system design requirements (if applicable). b) The ePA is periodically reassessed every 2 years.
SD10 | Threat Modeling is performed based on system classification | a) ISRM performs Threat Modelling (based on confirmation of requirement through AppSec Assessment). - Threat Modeling identifies security requirements that are needed to mitigate threats that pose a risk to the Information System (and related information) involved. - Security requirements identified as part of this process are added to the design requirements. - Existing, operationally live Information Systems are selected and onboarded on the basis of ongoing AppSec assessments. - Business System Owners support AppSec teams to onboard the Information System by providing resources, test environment, code and documentation in timely manner. - Required if Third Party Technology (TPT) is RT1 or RT2.
SD11 | Static Application Security Testing is performed for custom systems based on system classification | a) ISRM performs Static Application Security Testing for custom coded systems (based on confirmation of requirement through AppSec Assessment). - Scanning occurs during testing and prior to move of into Production. - Vulnerabilities or other issues identified during testing are resolved prior to migrating or otherwise releasing a system to Production. If not, appropriate handover occurs and issues (and risks) are documented and approved. - Existing, operationally live Information Systems are selected and onboarded on the basis of ongoing AppSec assessments. - Business System Owners support AppSec teams to onboard the Information System by providing resources, test environment, code and documentation in timely manner.
SD12 | Dynamic Application Security Testing is performed based on system classification | a) ISRM performs Dynamic Application Security Testing for Web Applications and Mobile Apps (based on confirmation of requirement through AppSec Assessment). - Scanning occurs during testing and prior to move of into Production. - Vulnerabilities or other issues identified during testing are resolved prior to migrating or otherwise releasing a system to Production. If not, appropriate handover occurs and issues (and risks) are documented and approved. - Existing, operationally live Information Systems are selected and onboarded on the basis of ongoing AppSec assessments. - Business System Owners support AppSec teams to onboard the Information System by providing resources, test environment, code and documentation in timely manner.
SD13 | Penetration Testing is performed based on system classification | a) ISRM performs Penetration Testing all RT-1 systems and all RT-2/RT-3 internet facing systems (based on confirmation of requirement through AppSec Assessment). - Vulnerabilities identified during Penetration Testing are resolved prior to release to the Production environment, or documented and accepted as part of handover. - Existing, operationally live Information Systems are selected and onboarded on the basis of ongoing AppSec assessments. - Business System Owners support AppSec teams to onboard the Information System by providing resources, test environment, code and documentation in timely manner. - Required if Third Party Technology (TPT) is (RT1 or RT2) and interfaced to another Novartis application. This can be completed by ISRM or a third party (e.g., through external certification and 3PAS assessment).
SD14 | Secure Architecture Review is performed based on system classification | a) ISRM performs a Secure Architecture Review (based on confirmation of requirement through AppSec Assessment). - This assessment results in identification of additional security design requirements that are included into the overall system design requirements. - Required if Third Party Technology (TPT) is interfaced to another Novartis application. b) Security Architects are involved (beyond the Security Architecture Assessment) if required as result of AppSec applicability analysis. - Security Architects support the Solution Architect in designing secure systems by providing security and remediation consultancy. - Security Architects review and evaluate whether additional requirements are needed from a security architecture point of view. c) Security architecture is documented as part of Architecture Handbook (or equivalent). - Architecture Handbook is mandatory for RT1 applications. - Architecture Handbook is reviewed annually.
SD15 | Development team completes Secure Design and Coding training | a) Development team members (Developers, Architects, Business Analyst, Testers and Project Managers) go through Secure Design and Coding training (or can present proof of equivalent training or certification), before development starts (based on confirmation of requirement through AppSec Assessment). - Project Manager (in case of a projects) or Business System Owner verify training records, to ensure successful completion of role specific training curriculum before commencing system design and development work. - If the event that the development is outsourced and the Third Party chooses not to use Novartis training material, then the Third Party provides equivalent training to their resources and provides training records upon request.
SD16 | Vital Integrity systems have input controls for key fields | a) For Vital Integrity Information Systems, requirements for input controls are identified (e.g. out-of-range values for a defined field type, invalid characters in data fields, missing or incomplete data).
SD17 | Development, Test and Production environments are appropriately set up | a) Where required, there are separate Development, Test and Production environments. - Access to Development, Test and Production environments is restricted to authorized individuals. - Access to the Development environment is segregated from access to the Production environment.
SD18 | Applications are classified | a) Applications are Classified based on legal requirements, value, criticality and sensitivity to unauthorized disclosure or modification following the Application Classification process. - eHLCCDs are completed and approved by Business System Owner, Technical System Owner, ISRM BISM/E and QA eCPL. - The relevance of legal and regulatory aspects is identified, including whether the application is GxP-relevant. - The classification information is kept up-to-date with any changes made to the application or its operational use. - eHLCCDs are completed for relevant applications provided by Third Parties.
SD20 | Web Applications include syntax validation, pre-screening and other input controls | a) Web Applications include syntax validation, pre-screening and other input controls to detect or prevent buffer overflow, SQL injection, cross-site scripting or malformed packets.
SD21 | Production data used in Test and Development environments is de-identified | a) Strictly Confidential, Sensitive Personal Information and PI-Full production data used in development and test environments is scrambled, de-identified, masked, or similar.
SD24 | Use of system maintenance tools and utility programs is controlled | a) The use of system maintenance tools for diagnostics and system maintenance, as well as utility programs that might be capable of overriding system and application controls, is controlled and access is managed using Privileged Accounts. b) The use of system maintenance tools for diagnostics and system maintenance is logged.
SD29 | Systems enable specific management of personal information | a) Systems that store or process PI-Full or Sensitive Personal Information or data enable this information to be selectively identified, exported, deleted, and have restricted access applied.
<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns="http://www.w3.org/TR/REC-html40">