Please enable JavaScript.

Coggle requires JavaScript to display documents.

DS&P (Control 1. TRAINING, AWARENESS AND ON/OFF-BOARDING (1.1 Project…

- - - - Crear el entrenamiento de DSP para los miembros activos del proyecto
    - - todos los non-staff augmentation y los staff augmentation regulados
    - - Al inicio, y actualizado una vez al año
    - - wmml: aqui poner cuando realizo el trainig
      - reglas de WPS: que los miembros conozcan las reglas y que se les va a ahacer una inspeccion
      - ITCS300 and ITCS104
      - Security Planning
      - Client and/or regulatory requirements
      - Proceso de on/off boarding
    - - training deck
      - programar revision anual del trainig
      - programar que se vuelva a tomar el training cada año
      - Evidecia de que los miembros tomaron el traing (registrarlo en la wml)
      - riesgos de miembros que no tomaron el training
    - - hacer el trainig basado en el Security Planning
      - Incluir training del cliente si es que hay
      - traquear que los miembros tomen el training
    - - Realizar los procesos
  - - - establecer y ejecutar (checklist) el onboarding
    - - todos los non-staff, y en los staff solo el checklist
    - - al inicio, con cada cambio mayor, y una revision minima al año
        
        y ejecutados con cada miembro entrante
    - - revisar que los miembros cubran los checklist y documentos contractuales (requisitos del cliente)
    - - Asegurarse que los miembros cumplan con los requisitos de remocion de accesos, continuar con los NDA y requisitos de contrato
- - - - For all non-staff augmentation projects.
    - - Management review over DS&P key processes and activities provides assurance on the continual execution of controls and risk management across the portfolio. Reviewing results from implemented controls (such as unauthorized users identified during an access revalidation activity) may identify ineffective controls that need improvement. The project’s risks, including any DS&P risks, should be reflected in IBM risk management processes such as 7-Keys, management self assessments and other mechanisms that may apply to ensure management awareness and action.
- - - - all non-staff augmentation projects that:
        
        In GBS, there are 4 criteria defined to help determine when performing a SOD analysis is good practice
        
        The contract or project is subject to national, state or other governing laws that require Separation of Duties (HIPAA, GLBA, state requirements, SOX).
        
        IBM workforce members providing GBS services do or will have update access in production (includes updating the application, infrastructure, using the application to update client data, etc.).
        
        IBM workforce members providing GBS services do or will have access to more than one environment (Development, Test and Production) or is able to promote from one environment to another (for example Development to Test or, Test to Production, etc.).
        
        SOD requirement is specifically called out in the client contract.
    - - Initial SOD analysis is performed at the start of the project;
      - updated to reflect workforce member role or access changes, or minimally reviewed for updates on an annual basis.
    - - Decreases the risk of fraud and misuse of code or assets that could occur when one individual is capable of executing conflicting tasks.
    - - Inventory
      - WMML
      - User ID list / Master Access List / System generated access lists
      - Workforce member roles, tasks and accesses.
      - Approved access request
      - Any other project specific artifacts that may assist in the determination of SOD tasks or role
    - - SOD Matrix and analysis.
      - Identification of conflicting tasks and roles.
      - Risks and actions to address risks.
      - Secondary controls
      - Updates to the project or security schedule
      - Management sign-off and client approval (if required by contract) on the analysis results
- - - - For all non-staff augmentation projects with access to client systems.
    - - At project start up
      - Updated when a new system/environment is introduced
      - Reviewed for updates with each major project change, or minimally on an annual basis.
      - The procedures are executed throughout the life of the project.
    - - Access to the client's environments should be managed, reviewed and approved by management to assure that only authorized personnel obtain and retain access.
    - - A documented User ID Administration Process is defined and implemented.
        
        The Process should cover access to systems, applications, tools, databases, data, data transmissions and environments to which the IBM workforce members have access.
        
        The process should reflect client requirements.
        
        The process document should be reviewed and approved by management one level up from the document owner and version controlled to demonstrate, at a minimum, an annual review of the process.
        
        The process should contain procedures for:
        
        Requesting access (including forms used to request access).
        
        Approving access.
        
        Granting access.
        
        Modifying access levels (including forms used to change accesses).
        
        Revoking user access (including forms used to remove access).
        
        If GBS manages the User Access process access should be removed according to the client requirement where they exist. If no client requirements exist access should be removed according to ITCS104.
        
        If GBS does NOT manage the User Access process (including when GTS manages the process) notification is to be given within 2 business days or not later than as required by the process owner’s process (if defined) for team members when they have been reassigned, separated or had a job change. (Process Owner may be the Client, a third party, GTS, etc.).
        
        IBM network access must be revoked within 24 hours for any team members (IBM employees, contractors, subcontractors) leaving the company according to ITCS104.
        
        Revalidating accesses.
        
        Managing shared and emergency user IDs