New User Access Form 2159



  • Does anyone have an example of new user form that is used to alert the IT department of new employees, their intended start dates, location and their computer software/hardware requirements?
    If you have a form that you are willing to share please email to my email address.
    Thanks
    MsStacy



  • Hi - While I don’t have a sample form used in our company, I’ll share some general ideas below that might be beneficial. This is a very rough draft just to illustrate mainly what components should go into these types of forms (hopefully electronic in setting it up, with perhaps one paper copy retained on file with the employee’s signature):

    SECURITY ACCESS REQUEST FORM FOR COMPANY: _______________________________________
    ACCOUNT DETAILS
    Date requested ____________
    Date approved ____________ by whom: ______________
    Name/Supervisor/Dept/Loc, etc …
    Employment Start Date _________
    Employee # ____ (some use SSN, but it’s always best to an internal #)
    Permanent or Temp status __ (and specify end date)
    Contractor or Consultant ___

    BASIC ACCESS RIGHTS – Grant access to following Systems (More technically oriented pointing to environments being accessed - usually in checklist format)
    TECHNICAL ENVIRONMENTS
    IBM - TSO, CICS, IMS, etc
    Windows - List domains or special servers
    Unix, Linux, AS/400, etc …
    Internet access (if restricted)
    Explain any special security needs - (e.g., for administrators, approvers, etc)
    APPLICATION SECURITY:
    Grant access to following applications (more business oriented)
    Sales,
    Finance,
    Accounting,
    etc
    Model User after: _________ (if employees fall into specific job roles where their rights are indentical to others in the work group)

    EMPLOYEE CONFIRMATION
    Signature _______________________ Date _________
    Employee’s selected PIN code ___ (have employee specify this, so that it can be validated with help desk)
    Signature: I agree to follow corporate policy guidelines, use this access for primarily business purposes, and recognize security monitoring will be in place at all times – e.g., have legal department specify the proper phraseology for this …



  • I have created a form and submitted it to IT for their input. Thanks for your help.
    MsStacy



  • I have created a form and submitted it to IT for their input. Thanks for your help.
    MsStacy



  • Also add a section in the end to note the results of the action taken:
    or a reference to Help Desk Ticket for details :
    FOR USE By IT dept Only

    Help Desk Ticket #
    Network Login Id assigned



  • Hello.
    A bit off topic here but in the form that harry posted I have noticed the: ‘Model User after: _________’
    isnt that approach (mirroring) a gray area?
    Its odd, because I have run into environments where mirroring was acceptable and even the preferred way to satisfy RBAC… on the other hand I have run into environments where it was strictly prohibited… I wonder whats the real answer here… hmm
    Thanx.



  • 404,
    I think it’s an issue of the approver knowing or having the necessary authority to approve the access.
    If everyone has the same access and approver can authorize it, then ‘same as’ or ‘modeled after’ performs the same function as RBAC.
    If the environment is one where access is not removed when people change areas, then ‘modeled after’ a user who has a significant amount of access could prove risky at best. (And this could also be a SD.)
    Another factor could be special authority (either levels or areas). If a user is granted the authority to reset local passwords or a programmer is given (temporary) access to production, and ‘modeled after’ is done without some thought, then inappropriate access could be assigned and it may require more than a single approval to justify the access. Access should always be reviewed in a ‘modeled after’ approach if it is allowed.



  • I have noticed the: ‘Model User after: _________’
    isnt that approach (mirroring) a gray area?
    Hi - I agree with 404’s concerns – as in theory, security rights should be minimalistic and specified in detail individually for each user … However, in actual practice (and particularly in a large corporate setting), folks are generally placed into security ‘groups’. The model after concept is usually an approach of convenience for initial setup, where as afterwards more specific rights may be granted as needed for a user or developer’s job roles.
    The ‘model after’ approach might say to grant ‘user A’ minimal rights to a specific server that would be used by other members of their department. It might also help get them setup with read access to certain applications they support and the overall test environment. It may also help setup the PC workstation environment with clients and tools as well. However, the ‘model after’ approach would not to give them all the specific access rights of the user they are being ‘modeled after’ (i.e., it’s more of a generic approach as to which group of users the new person is associated with to help security/techs setup the new employee with minimal basic access) .
    This approach works well when you have maybe a dozen folks doing the same function as part of a unified team. Also, it could be used where ‘employee B’ is a replacement for ‘employee A’ who has 'moved on to ‘greener pastures’ 😉



  • Thanks for explanation 🙂


Log in to reply