# Infor LN VRC Development and Change Control Checklist > Source: https://netray.co/tools/infor-ln-vrc-development-change-control-checklist > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Free Tools ## Short answer IT general controls checklist for custom development on an on-prem Infor LN 10.x system: VRC layout, developer access, change approval, transport and the evidence auditors ask for. ## Category infor-ln ## Erp Infor LN ## Audience - IT auditor - LN development lead - LN system administrator - IT manager ## Tool **Kind:** checklist **Groups:** #### VRC structure **Items:** **Text:** A customer VRC is derived from the standard update VRC for each customized package, and standard VRCs are never edited **Critical:** true Separate package combinations exist for development, test and production **Text:** No development happens in the production environment; production holds only transported objects **Critical:** true The VRC tree and derivation are documented and match what is in the system Expired or obsolete customer VRCs are identified and not attached to active package combinations Each customized object carries a header comment with change number and author #### Developer access **Items:** **Text:** A current list exists of users with developer authorization and the package VRCs they can change **Critical:** true Access to Program Scripts / Libraries (ttadv2530m000) and other ttadv development sessions is limited to developers Developers check software components out and in through LN Studio rather than editing on the server **Text:** No developer has developer authorization in production **Critical:** true Use of bsp, baan and root accounts is restricted, named in a register and logged Leavers lose developer authorization on the day they leave Developer authorization changes are converted to runtime and reviewed, not left pending #### Change approval **Items:** **Text:** Every script, DLL, table, form or report change is linked to an approved change request **Critical:** true DAL and user exit (UE) code changes have a documented peer review Table definition changes are approved by the data owner because they can trigger reconfiguration Report layout changes in Reports (ttadv3530m000) or report personalizations follow the same approval path Emergency changes have a defined fast path and are approved retrospectively within a set number of days **Text:** Testing evidence is attached to the change before transport to production **Critical:** true #### Transport and patching **Items:** **Text:** Customizations reach test and production by a repeatable transport (for example a PMC solution or patch built on development), not by manual copy **Critical:** true The person who transports to production is not the developer of the change Infor PMC solutions are installed in test first and reviewed for collisions with customer VRC objects After each transport, object versions in production match the approved versions in development Transport logs are kept for the audit period #### Evidence for auditors **Items:** **Text:** Quarterly export of LN users with active status, user type and developer authorization **Critical:** true Change log listing changed objects, change number, approver, transport date **Text:** Quarterly review of developer and superuser access signed by the system owner **Critical:** true Reconciliation of production object changes against approved changes for the period Written statement of how emergency access was used during the period **Scoring Note:** Critical items map to the controls auditors usually test first: segregation of development and production, restricted developer access, approved changes and periodic review. Treat any unchecked critical item as a likely audit finding. ## Content **Intro:** This checklist covers IT general controls around custom code on an on-prem Infor LN 10.x system: how VRCs are laid out, who can develop, how changes are approved and transported, and what evidence you hand auditors. It is about development control, not the periodic user access review. **Sections:** #### Why on-prem LN customers need their own evidence **Body:** People often search for an Infor LN SOC report expecting it to cover their system. The SOC reports Infor provides relate to Infor's cloud services, where Infor runs the infrastructure and the change process. When you run LN on your own servers, you operate the controls: who can change scripts, how changes reach production and who reviews access. Your external auditor will test those controls directly, usually by sampling changes and checking for approval and testing evidence, and by reviewing developer and superuser access. This checklist is the set of controls and the evidence they produce. #### Where this lives in LN **Body:** Customizations live in customer VRCs derived from the standard update VRC, so the standard code stays intact and PMC solutions can still be installed. Scripts and libraries are maintained in Program Scripts / Libraries (ttadv2530m000), reports in Reports (ttadv3530m000), and developers normally work through LN Studio, which checks software components out to a developer and back in. Developer authorization and user types are held in user management (User Data, ttams1100m000) and must be converted to runtime to take effect. Package combinations bind VRCs to environments, which is how you keep development objects out of production. #### How to use it **Body:** Run it once as a baseline with the development lead and the system owner, mark what exists today and attach evidence to each ticked item. Unchecked critical items become remediation actions with owners. Then rerun it every quarter as part of the access and change review, exporting the PDF as the review record. For the change log, sample five to ten production changes per quarter and confirm each has a change request, peer review for DAL or UE code, test evidence and a transport by someone other than the developer. Keep the periodic user access review on its separate checklist. #### Common findings **Body:** The usual findings on LN systems are predictable. Developers keep developer authorization in production for support reasons. The bsp account password is shared and its use is not logged. Small report changes skip the change process because they feel harmless. Production objects were edited directly during an incident and never reconciled. Each of these is fixable: a break-glass account with logging for production fixes, named admin accounts, and a rule that every object in a customer VRC must trace to a change number. **Cta:** If you want auditors and IT to ask your LN system in plain English which objects changed and under which change number, we can set that up on your own servers. **Faq:** #### Does Infor provide a SOC report for Infor LN on-prem? **Answer:** Infor's SOC reports cover its cloud services, not a system you host yourself. For on-prem LN, your organisation operates the change and access controls and must produce its own evidence. A SOC report from your hosting provider may cover infrastructure controls, but not LN development and access within the application. #### How do I list active Infor LN users for an audit? **Answer:** Export user records from User Data (ttams1100m000) with user type and status, and compare them against HR leavers and your licence position. Include developer authorization and superuser flags in the export, because auditors focus on those. Keep the export with a dated sign-off by the system owner. #### What should an LN technical consultant follow for change control? **Answer:** Develop only in a customer VRC on the development environment, check components out and in through LN Studio, link every change to an approved request, get DAL and UE code peer reviewed, and hand transport to production to someone else. Record each changed object with its change number. #### Is this the same as a user access review? **Answer:** No. A user access review checks that each user's roles and authorizations still fit their job. This checklist covers development: who can change code, how changes are approved and transported, and the evidence for that. Most audits test both, so run them as separate, linked reviews. ## Search terms infor ln soc report, infor ln technical consultant, infor ln active users, infor ln studio, infor ln vrc, infor ln change control, infor ln itgc, infor ln sox controls --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json