3rd Party Vendor Documentation Requirements 2509
JLewis last edited by
Hello again forum,
i have an issue that is looming over my head a bit and it deals with vendor management. The organization i am working for has great reliance on 3rd party vendor applications, with this reliance comes an outsourced risk in the fact that they are invovled in maintenance of current applications. This maintenance requires them to access our system, and we are currently implementing ‘fireId’s’ that are activated and deactivated as needed for hotfixes, service packs and other general updates and other change management process that require vendor invovlement. With that being said, currently we do not have a structured documentation process that they are to follow, and what i was hoping to create is a standard for vendor documentation requirements but i cant seem to find anything out there that states exactly what is needed in this documentation.
Any help you can lend will be GREATLY appreciated.
harrywaldron last edited by
Hi JL - As a starting point, I’d recommend some of the following from a documentation perspective:
– Develop policies, standards, and procedures related to 3rd party system access, testing, and maintenance on an internal basis
– In future new or renewed contracts with vendors, you might use some newly written language to tighten controls if you need to (e.g., access monitoring controls, assurances of complete customer confidentially, and other fiduciary concerns)
– Retrofit and use some of the existing SDLC approaches for internal development for vendor maintained systems, (e.g., ensure they undergo change management, isolate TEST/UAT/PROD, setup UAT/TEST environment if not present, etc).
– The use of FIREIDs is indeed an acceptable practice for hot fixes, but shouldn’t be used for normal everyday maintenance. You might look at granting special accounts highly monitored and restricted if you have daily access by 3rd parties.
– Also, as another idea maybe the patch can be handed off to IT professionals so that it’s internally applied and tested to better protect the confidentially of customer info. The application is better learned for support purposes as well. You all may be doing this anyway.
– Some of these links looked promising
http-and-#58;//www.google.com/search?hl=en-and-q=IT policies system maintenance by external parties
JLewis last edited by
Awesome, thanks again Harry, you always have the good points.
Currently we have a lot of vendor managed applications that require their input on any process ran against their product. Everything from maintenanace to implementation of new modules, etc. That is what we are trying to change. Some vendors seem to have to much control and input into what happens in our environment, and we are trying to instill aggreements, both service and maintenance, that restrict their invovlement as well as make it mandatory that they give us enough information to handle certain aspects of application maintenance and service.
I will definatley look into the link you have posted, as im trying to find as many examples as i can, and learn what works and what doesnt as this topic seems to be all over the map and specific to your organizational needs.