Autodesk Construction Cloud in a Closed Environment: Checks Before the Pilot

What to check before the pilot

By “closed environment” we usually mean an environment where access to data and services is tightly restricted: proxies and allowlists are in place, sometimes there is no direct internet access, and there are requirements for data residency and mandatory auditing. In such conditions, Autodesk Construction Cloud is evaluated not only for team usability but also for whether the service can be safely and legally integrated into your IT environment.

Pilots most often fail not because of missing features but because of access and data issues. A user might not sign in due to SSO, a contractor may not get correct guest access, or security may stop the launch if it’s unclear where files are stored, how to export them and how to obtain event logs for investigations.

Before procurement and training, it’s better to close topics that are expensive to change later:

• Identification and access: who and how signs in, how quickly access is removed on the day of termination, how contractor access is granted.
• Data: where data is physically stored, how encryption and backups are handled, and who has export rights.
• Integrations: which corporate systems are required at start (EDMS, mail, file shares, user directories), what can be done via API and what will remain manual.
• Logging: which events are recorded, how long they are retained, how to export them to SIEM, and how to validate user actions.

It’s useful to read and discuss this section together: IT (network, proxy, integrations), security (threat model, audit, policies), the BIM coordinator (processes and roles), and data legal counsel (contracts, residency, liability). If an external view is needed, system integrators usually provide a pre-check so the pilot won’t stall on access, network rules and formalities.

Requirements map: security, compliance, processes

Before the pilot, it’s important to agree not only "connect or not" but also what you consider acceptable in terms of risk and processes. It’s most convenient to capture this as a short requirements map: who approves decisions, which data are involved, what restrictions apply and how success is measured.

First, gather requirement owners and agree their decisions are final. Typically you need IT (network, accounts, support), security (policies, risks, logging), legal and compliance (contracts, liability, retention), operations (backups, incidents, procedures) and the project office or client (how it should work in the field).

Then record data classes. Minimally split into:

• project files (drawings, models, photos),
• personal data (e.g., staff data in reports and access logs),
• commercial secrets (estimates, contract terms).

For each class, specify what is forbidden and what is allowed: where it can be stored, who can see it, how long to keep it and how access is granted.

Separately note the closed-environment restrictions: is permanent internet access required, is working via proxy allowed, which external services are forbidden and who maintains allowlists of domains and addresses. Pilots often fail not because of functionality but because these restrictions weren’t agreed in advance.

Finally, define pilot success criteria so there’s no later dispute about whether it worked. Four to six criteria are usually enough, for example:

• users complete 2–3 key scenarios without workarounds;
• accesses are granted and revoked according to policy;
• event audit is available and understandable to security;
• data export and project closure are possible by procedure;
• support knows what to do during failures and incidents.

If the pilot is done with an integrator, approve the requirements map before setting up the test stand. That reduces rework during the pilot.

Data storage: residency, encryption, backups

For the pilot it’s essential to understand in advance where files, metadata, comments and logs will reside. In the Autodesk Construction Cloud closed-environment context, residency often becomes a blocker not because of the service’s capabilities but due to client and regulatory requirements.

First, record which data types you will upload in the pilot (drawings, models, photos, correspondence, reports) and map them to storage location requirements. If some data cannot be stored outside the country or in a public cloud, identify that before projects are put into the system.

What to confirm in writing

Ask your security team for the list of documents they need to see during approval. They usually check specific formulations: encryption in transit, encryption at rest, key management, and who on the provider side has access.

A short minimum checklist:

• In which region/country pilot data and backups are stored.
• Which data are encrypted and at which stages (in transit, at rest).
• How separation of data between projects and teams is handled (so contractors cannot see others’ data).
• What is included in the service’s backup and what remains your responsibility.
• Retention periods, deletion and return of data after the pilot.

Backups and exit from the pilot

Verify the recovery scenario: who initiates it, how long it takes, and what counts as successful recovery (for example, model + change history + access rights). If multiple contractors participate, agree in advance who extracts the final archive and where it is stored afterwards.

A separately described scheme “export – storage – integrity check – access” helps here. It’s useful to formalize it as a short procedure: who may export, where the golden copy is stored and who confirms completeness.

Access and identity management

In a closed environment, access is the main control lever, not a checkbox. Before the pilot, agree who owns the Autodesk Construction Cloud environment, who creates projects, who assigns roles and how changes are recorded. When administration is split between IT, security and project leads, extra permissions usually appear and problems start.

Check the model of roles and groups. It’s more convenient when access is granted via groups (by function and project) rather than manually per user. Also clarify where the source of truth is stored: ACC, your IDM system or an outdated policy document.

SSO, MFA and account lifecycle

Decide how sign-in will work: corporate SSO or separate accounts. In closed environments MFA is almost always required. Verify whether the chosen MFA method is supported in your environment (hardware tokens or corporate apps) and how it will work for external contractors.

If AD/LDAP integration is planned, run the user lifecycle: creation, department change, lockout, termination. The critical question is how quickly access in ACC is removed after disabling the domain account.

Contractors and temporary rights

Set a rule in advance for external organizations: access only to specific projects and only to required modules. Practical minimum procedures before start:

• access by request with project owner approval;
• role- and time-limited permissions;
• revoke access on the day work ends;
• change of responsible persons without orphaned admins;
• regular (e.g., monthly) review of active users and permissions.

Example: a general contractor runs a pilot on one site and connects three subcontractors. If all are made Project Admins, they will see extra documents and settings. Assign task-specific roles (view only, RFI) with a 30-day limit to reduce leak and accidental-change risk.

If the pilot involves an integrator, clarify in advance who administers access and who audits permissions to avoid dependence on a single person’s manual actions.

Integrations: apps, APIs, exchange with corporate systems

In closed environments, integrations often break not because of Autodesk but because of the real environment: different CAD versions, limited rights on workstations, proxies and banned plugins. Describe which integration points you need daily and on which workstations they must work: designers, technical supervision, contractors.

What to check for apps and workstations

Start with a practical run: open a sample project and follow the path from model to comments. Verify that your BIM/CAD tools and viewers publish and update models correctly, don’t create excess local copies, and work adequately on weak workstations or thin clients if used.

Also check templates, classifiers and file naming rules used in the company. A frequent closed-environment issue is plugins that require admin rights to install or update — these conflict with workstation policies.

Next, move to APIs and connectors. List systems to integrate: document management, ERP, Service Desk, archive storage, corporate user directory. Describe the data flow: which fields and files go to the cloud, what returns, where intermediate caches and logs appear.

Closed environment and gateways

If direct exchange is forbidden, decide where the intermediate gateway will be (a dedicated DMZ server or an integration contour). Verify who manages it, how it’s updated and how projects from different contractors are separated.

For the pilot a short test plan is sufficient:

• one project, two contractors, different roles and permissions;
• one integration action (create request/comment) and a confirmation of status back;
• control of copy locations: local, on the gateway, in corporate archive;
• resilience test: connection loss, retry, duplicates;
• integration logging: who, when, what was transferred and what changed.

Network and perimeter: proxy, allowlists, connection stability

For a pilot in a closed environment the network is often the main blocker. Even if internet access is formally allowed, details like proxies, certificate checks and DNS configuration break sign-in, file upload and synchronization.

First, record how users will access external services: direct, via corporate proxy, via security gateway, or from a dedicated segment. Verify required domains and ports are allowed, and TLS is not interfered with by policies. If your organization has an internal CA, ensure the root certificate is trusted on workstations and proxy servers.

To avoid spending the first day chasing log causes, agree the basics before start:

• list of allowed domains and ports, TLS and certificate chain requirements;
• proxy rules (authentication, file size limits, timeouts);
• SSL inspection policies and exceptions for critical services;
• basic services: DNS, NTP (accurate time), access to CRL/OCSP;
• firewall segmentation rules between clients, admins and contractors.

Then verify segmentation. Keep designer workstations, admin machines and contractor devices in separate zones and give minimal external access. This reduces risk and eases security approval.

Before the pilot, prepare a short measurement plan, especially if large models are used: latency and packet loss to exit points, upload/download speed for large files, stability over the workday, behavior on disconnect and re-sync.

Example: contractors operate through a separate segment with proxy and SSL inspection. If exceptions and certificate trust aren’t configured, some ACC operations will hang without clear errors.

Logging and audit: events, exports, SIEM

In a closed environment logging serves two purposes: quickly finding incident causes and proving actions were controlled. Before the pilot you must know not only “are there logs” but what they contain, who can see them, how to export them and how long to keep them.

Typical minimum event set for security and internal control:

• authentication (successful/failed sign-ins, sign-outs, password changes, MFA);
• permissions (grant/revoke roles, group changes, access setting changes);
• data actions (upload, download, delete, rename, move files and models);
• administration (project setting changes, integration connect/disconnect);
• exports (who generated an export, when, volume and destination).

Then check retention and depth. A common pilot mistake: logs exist but are retained too briefly, while an investigation needs a month or quarter of history. Agree retention targets per your security policy and where logs are stored: inside the perimeter, with backup and restricted access.

Test log export manually before start: available formats, scheduled export capability, and who can perform exports. It’s practical to separate duties: a project admin should not be sole controller of data and audit.

For SIEM it’s often better to send selected meaningful events with context: sign-ins, permission changes, mass deletes, unusual downloads, export operations. In the pilot agree correlation rules and required fields (user, project, IP/host, time, action, object).

Simple test scenario: a contractor reports “files disappeared.” From logs you should be able to restore:

• who deleted or moved files and in which project;
• whether permissions changed before that;
• who downloaded those files and when;
• whether exports or bulk operations were performed.

Exports and archiving: retaining control over data

If Autodesk Construction Cloud in a closed environment is treated as a working platform, decide in advance what data you must be able to extract at any time and in what format. This reduces the risk that the pilot ends and project evidence stays “inside” the service.

Create a list of items that must be included in exports. Usually you need not only files but context: who, when and which version was approved.

• original files and all versions (including notes and comments);
• metadata (attributes, statuses, relationships, participants);
• reports and registers (comments, inspections, RFIs, approvals);
• action logs for key operations;
• handover materials for the client (deliverable sets, lists, summary exports).

The archive format should be suitable for long-term storage and transfer between organizations. Verify exported files open without relying on the project’s internal structure and that names, dates, versions and IDs are preserved. Also check whether reports can be exported in a flat format (for example, a table) with a clear manifest describing archive contents.

Next, agree on frequency and process owner. In a closed environment “someone will export at some point” almost always means nobody will. Typically assign the role to IT or the project office and place storage in corporate archived storage with backups.

To prove archive integrity use a simple control scheme: manifest, hashes, export log and a copy stored where edits are prohibited. This is crucial if the archive can be used as evidence.

Write the exit plan before starting the pilot: how many hours for a final export, who confirms completeness, where the golden copy is stored and how it is handed to the client.

Step-by-step pre-pilot checklist

To make a pilot in a closed environment yield honest results, record what you will test and how you will prove findings. Otherwise it becomes a set of disconnected tests with no evidence for security and procurement.

Steps before start

1. Choose 1–2 typical processes with the biggest pain: approval of design documentation, issuing working documentation to contractors, or clash coordination. Describe participants, statuses and output artifacts.

2. Prepare test data and users. You need at least two sets: a small one (quick run) and a large one (performance and export). Pre-create roles: client, lead designer, contractor, auditor.

3. Configure access: SSO/MFA, roles and rights, contractor invitation model. Immediately test how access is disabled after contract end and how project separation by organization works.

4. Check network and workstations: proxy, allowlists, connection stability, port limits, workstation and browser requirements. In closed environments the route to the service usually breaks before the function does.

5. Run critical checks: integrations and data exchange with corporate systems, logging (which events are recorded and how they are exported), exports and project archiving. For each test record date, conditions, result and artifact (log, export file, screenshot of a setting).

Then consolidate results into a single checklist: passed, passed with limitations, failed. Assign each risk an owner and remediation timeline. If the pilot is with a contractor or integrator, agree in advance who collects evidence for security and who is responsible for retesting.

Common pilot mistakes in closed environments

Worst pilot stories usually stem from missing basic agreements and settings rather than missing functionality.

Organizational slip-ups

Often the pilot starts without an owner: nobody approves project structure, roles, invitation rules or what counts as the official document version. As a result, permissions balloon and responsibility blurs.

Another common mistake is mixing test and production. When training models and real projects share one space, permissions leak and users get used to workarounds.

Technical surprises caught in advance

Proxy configuration and SSL inspection are usually addressed last. Then uploads fail, previews won’t open and users are blamed. Agree which domains and traffic types are allowed and who handles exceptions beforehand.

Export and archive plans are often forgotten. Without an exit plan (what data to export, in which format, where to store and who signs off), the pilot becomes a dependency on current settings.

Finally, logs are collected “for the record.” To make logging useful, answer three questions in advance: which events are critical, who monitors alerts and how quickly can the initial picture be assembled.

Example: in a large organization client and contractors work in parallel but security requires audit exports for file actions. If no data owner is assigned and export-to-SIEM is not described before the pilot, week three stalls on approvals rather than project work.

Example pilot scenario: large client and contractors

Imagine a pilot at a single site: a large client (client service), a general contractor and three subcontractors (utilities, finishing, equipment supplier). Each has different access levels: the client sees and approves everything, the general contractor coordinates, subcontractors see only their sections and shared clashes.

Internet in the closed environment is allowed only via corporate proxy, and security requires logging of all admin actions and regular data exports to an internal archive. Build the pilot around three tasks: model exchange, version control and quick comment approvals without email.

Before start the team approves an access matrix: who may invite whom, which external roles are allowed and what to do when a contractor staff member is replaced. Simultaneously verify the proxy doesn’t break sign-in, model uploads or notifications.

What to check in the pilot to avoid surprises after a week:

• external invitations (who creates accounts, how identity is confirmed, how quickly access is disabled);
• data separation (folders and permissions for subcontractors, export restrictions);
• logs (which events are recorded, how often they can be exported and where stored);
• export and archive (regular export of models, drawings, comments and metadata, and verify restore from archive);
• response procedures (what is an incident and who can stop the pilot).

Success criteria should be agreed beforehand: comment approvals become faster (e.g., from 3 days to 1), no security policy violations occurred, and logs and exports cover key actions and pass internal checks.

Quick checklist and next steps

Run a quick 15-minute check before the pilot and record who is responsible for what. This saves weeks of questions about data, logs and exports later.

Short checklist:

• Access: who is the administrator, how roles are issued, are test accounts available, how does disabling work.
• Network: proxy/firewall, allowlists, connection stability, who approves network settings.
• Data storage: where files are stored, residency requirements, backups and retention.
• Logs and audit: which events are needed, where they are exported, who reads them and how quickly they respond.
• Exports: which formats are allowed, where the archive sits, how export completeness is verified.

To make the pilot auditable, create a “pilot folder” in an approved corporate archive and store artifacts there: the agreed requirements and role matrix, data schema, network settings, test results (export, restore, log checks), protocols and confirmations.

Invite security and legal again when you finalize the data model and export rules: that’s where retention periods, transfer restrictions and audit evidence usually appear.

If you need to align network, workstations, infrastructure and support processes for the closed environment, it’s often easier with a system integrator. For example, GSE.kz as a manufacturer and integrator of IT infrastructure in Kazakhstan can cover adjacent pilot tasks (workstations, servers, perimeter, 24/7 support) so technical limitations don’t block testing processes and data control.