Infor LN & BaanFree checklistPDF, Excel, Word exportInfor LNAll Infor LN and Baan tools

Infor LN VRC Development and Change Control Checklist

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.

0%

0 of 29 items complete

9 critical items still open - these are the highest-risk gaps.

Download checklist:

VRC structure

Developer access

Change approval

Transport and patching

Evidence for auditors

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.

Get your LN change controls reviewed before the audit

Send us your completed checklist and a sample of recent changes and we will point out the gaps an auditor is likely to raise.

Optional. The tool and every export work without this. No spam.

Was this tool useful?

Why on-prem LN customers need their own evidence

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

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

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

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.

Frequently Asked Questions

Does Infor provide a SOC report for Infor LN on-prem?

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?

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?

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?

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.

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.

ArchRay builder
Design the on-prem AI stack for Infor LN and Baan: model, GPUs, RAG pipeline, guardrails
See memory, speed and cost as you swap parts, then export the diagram. Free, in your browser.
Open the builder

Keep exploring

Free tools

ERP fixes and how-tos

Guides

AI on your ERP

Integrations

Comparisons

Software