An old project file stays accessible
A drawing, image set or presentation uploaded during a redesign can remain available after its visible link is removed. The practice needs a deliberate inventory of material intended for public use.
Website security for architecture and engineering practices
Protect your practice online.
Website security for project portfolios, enquiries, downloads and collaboration links, with clear responsibilities for your practice and providers.
Your portfolio is public. Your project information may not be.
A visitor can move from a completed-project gallery to a project brief, a technical download or a client sign-in link in a few clicks. Those routes need different controls, even when they share the practice’s name.
A new-project enquiry reaches the wrong person
Office moves, mergers and staff changes can leave forms tied to an old mailbox or external account. A successful-looking submission can conceal a handoff that nobody owns.
A client link sends visitors somewhere unexpected
The public website may direct clients to a separate common data environment or file-sharing provider. Incorrect destinations create confusion at the point where users expect an official route.
Portfolio editing comes with excessive access
Photographers, designers and marketing contractors may need to update project stories without changing website software or enquiry recipients. Publishing tasks and administrative privileges should be considered separately.
Review the journeys your clients and collaborators actually use.
Start with the functions on your site, then identify their information, owners and technical boundaries. A public portfolio, a restricted document area and an external project platform should not be treated as the same environment.
Project portfolios and practice profilesApproved images, case studies and publication access
Publish the work you intend people to see.
Project galleries carry the practice’s reputation. They may include architectural photography, renderings, location details, design descriptions and downloadable credentials. Record which material has been approved for public distribution, which version is current and who can authorize a replacement. Security work can support the publishing process while the practice retains responsibility for content and permissions.
An agreed review can examine CMS roles, relevant media routes, old campaign pages and included settings that affect publication. A retired project page does not by itself establish that every associated file has been removed from public reach. Where the concern involves unpublished material, agree a small, non-sensitive example and suitable evidence handling before investigating.
Portfolio redesigns deserve a release checklist. Confirm the approved project list, media destinations and editing responsibilities before migrating content. Do not use a live confidential drawing set as a test fixture. Copyright clearance, photographer agreements, client approval and the accuracy of project credits remain decisions for the practice and its advisers.
What to establish for this journey
- Approved public inventory
- List project pages, downloadable credentials and the person responsible for publication.
- Publishing permissions
- Distinguish content editing from administrative and software-changing access.
- Retired material
- Agree what should happen to older pages and associated public files.
New-project and appointment enquiriesBrief forms, office recipients and scheduling links
Give every project request a responsible destination.
An architecture or engineering enquiry may be routed by office, discipline, project type or location. Map each form and scheduling link to its intended recipient and any CRM or notification service. A general contact address, a careers form and a request for a project consultation serve different purposes and should have separate expectations.
The defined website scope can include form configuration, included abuse controls and recipient routing under your control. Agree functional checks and sample information in advance, with a named contact who confirms the result. Avoid live appointment creation or unsolicited messages as informal tests. Provider-owned systems need their own authorization and appropriate test facilities.
A first enquiry rarely needs the full design package. Explain how someone can describe the location, project type and concern without sending private site plans, access arrangements or a client’s complete brief. If uploads are offered, discuss file handling, access, retention ownership and a suitable later exchange process during scoping.
What to establish for this journey
- Office and discipline owner
- Identify which team should receive each kind of project request.
- Form-to-recipient handoff
- Record notifications, included integrations and how receipt will be checked.
- Proportionate information
- Define what belongs in an initial enquiry and what should use an agreed later channel.
Technical resources and document downloadsPublic brochures, specifications and restricted material
Make the intended audience part of the download design.
A practice website can host capability statements, planning guides, product details, research papers or example specifications. Identify which resources are deliberately public and which belong in an access-controlled environment. A file’s professional appearance does not establish that it is suitable for unrestricted publication.
Discuss how the actual site implements access. A form placed before a download and an authenticated document repository are different arrangements. Where restrictions are required, the scope should name the features, permitted accounts and checks to examine them. Do not assume that an unlisted URL provides the access model the practice intended.
Separate marketing resources from project deliverables. Working CAD files, building information models, tender documents and security-sensitive site information can require a different system and handling process. The website engagement can document the boundary and included controls; it does not validate engineering calculations, document issue status or the suitability of a specification for construction.
What to establish for this journey
- Resource classification
- Identify public guidance, practice credentials and material intended for restricted use.
- Defined access behaviour
- Agree the expected audience and the actual controls included in the review.
- Document ownership
- Name who approves versions, withdrawals and the destination for project deliverables.
Client portals and collaboration handoffsOfficial links, project platforms and access boundaries
Know where the public website ends.
A client-login button might lead to a common data environment, a document-management service or a private website feature. Map those destinations individually. The practice’s website administrator and the project-platform administrator may be different people, particularly where a client or lead consultant provides the collaboration environment.
Website-side review can cover agreed links, redirects and included configuration. Testing an authenticated platform requires explicit authority, named environments and permitted methods. Participation in a design team does not by itself grant authority to assess the client’s systems, other consultants’ accounts or a platform provider’s infrastructure.
Review portal links when a project closes, an office changes provider or a website partner hands over. Identify who approves destination changes and who handles account recovery. Use approved sample accounts and fictional project content if authenticated checks are included. Avoid copying real models or document registers into a website-security enquiry.
What to establish for this journey
- Official destination
- Confirm the approved platform and the owner of each public handoff.
- Explicit authority
- Agree any restricted-area checks and permitted samples before access.
- Project transitions
- Assign responsibility for link changes and account reviews as teams change.
The systems, checks and technical work included in a review are agreed before access or testing.
Build website safeguards into studio operations.
A portfolio launch or new practice website should not depend on a single person remembering every form, extension and account. Connect routine safeguards to the way your team publishes and changes providers.
- Access that follows the assignment
- Identify principals, marketing staff, external designers and developers with website privileges. Review access when a contract ends or a role changes. Discuss supported sign-in protections and firm-controlled recovery contacts rather than leaving ownership with a former supplier.
- Portfolio release and approval checks
- Before a new project launch, agree the approved media, public downloads and affected enquiries. Keep the content approver and technical release owner visible. Check important destinations after included changes, with rollback authority understood before the release.
- Maintenance across the actual dependencies
- Record ownership of the CMS, theme, extensions, hosting and embedded tools such as maps, viewers and scheduling widgets. Third-party code deserves a named owner and review process. Changes to an embedded tool can affect the website independently of a portfolio edit.
- Recovery beyond a folder of images
- Establish what website files, database and configuration are covered by backups and who can restore them. If an isolated restore exercise is included, agree its checks. A website backup should not be assumed to include a separately hosted model viewer, CRM or common data environment.
For practices with different publishing and collaboration needs.
Scope follows the website’s functions and the systems it connects. A small design studio and a multidisciplinary firm may need different checks even when both publish project portfolios.
Architecture, interiors and landscape studios
Focus on approved photography, project narratives, enquiry forms and the people who maintain them. Include older media routes when a portfolio has been rebuilt.
Civil, structural and building-services engineers
Map discipline enquiries, technical resources and external project-platform links. Keep website review separate from assessment of design software or engineering outputs.
Multidisciplinary and multi-office practices
Identify central publishing responsibilities, office-level recipients and brand or domain ownership. Mergers and supplier changes are useful moments to clarify access and routing.
Practice managers and website partners
Work from a shared list of approvers, maintainers and provider contacts. Agree practical remediation and handover without turning website access into unrestricted access to project systems.
Start with the route that concerns your practice.
We turn the website concern into a defined engagement, then coordinate included work with the people responsible for publishing, hosting and linked systems.
Describe the public journey
Share a portfolio page, enquiry route, download or sign-in link. Explain what should happen and the concern using a public URL or a non-sensitive example.
Agree ownership and limits
Name domains, environments, authorized contacts and providers. Confirm permitted methods, evidence handling, important deadlines and excluded project systems.
Review and plan changes
Examine the agreed website areas and explain findings in context. Separate confirmed observations from provider questions, then agree priorities and included implementation.
Verify and document the handover
Check the relevant routes after included changes. Record completed work, remaining tasks, responsible owners and any continuing-care arrangements.
A handover your practice and providers can act on.
The report should connect website observations to publishing and client-facing functions. Evidence depth, remediation and follow-up are established in the proposal.
A defined website inventory
Named domains, portfolio routes, enquiries, resources and collaboration handoffs reviewed, with access limits and excluded environments recorded.
Findings with practical context
What was observed, why it matters to the included website function and the suggested next action. Restricted evidence follows the agreed handling process.
Actions and accountable owners
Included fixes, recommendations and dependencies assigned to the practice, website partner, host or relevant platform owner.
Verification and recovery notes
Checks completed after changes, unresolved limitations and recovery responsibilities. Continuing monitoring or incident availability needs an agreed support scope.
Agree the website scope without blurring professional responsibilities.
The written engagement identifies the systems and work included. These boundaries make it easier for principals, IT contacts and external providers to coordinate decisions.
Public publishing and website controls
- Discussed in this review
- Named portfolio pages, approved resources, agreed CMS access and included hosting settings.
- Agreed separately when needed
- Publication rights, accuracy of project credits, private client infrastructure and unlisted domains.
Enquiries and document routes
- Discussed in this review
- Agreed form handling, recipients, public downloads and explicitly authorized restricted website features.
- Agreed separately when needed
- Real client briefs, live bookings, unrestricted document repositories and unapproved uploads or notifications.
Collaboration and project platforms
- Discussed in this review
- Approved public links, redirects and any specifically authorized website-side integration settings.
- Agreed separately when needed
- Provider infrastructure, client-owned common data environments, CAD/BIM tools and other consultants’ systems without separate scope.
Professional and regulatory assurance
- Discussed in this review
- Website observations, agreed technical actions and verification within the named environment.
- Agreed separately when needed
- Design validation, structural safety, building-code advice, document certification, compliance assurances or security guarantees.
Choose support around the next website decision.
A focused review and continuing maintenance address different needs. Scope, quote, timing and provider coordination are confirmed before work begins.
A defined practice-website assessment
Useful before a portfolio redesign, new office launch, provider handover or investigation of a particular form, download or client link.
- Named functions and permitted checks
- Priorities tied to website use
- Included actions and clear handover
Continuing website protection
Discuss ongoing care where publishing access, software maintenance and release checks need reliable ownership alongside project delivery.
- Agreed maintenance and review tasks
- Defined reporting and escalation
- Recovery and provider responsibilities
Bring the website context, not the project archive.
A public address and a brief explanation are enough to enquire. Access, evidence and suitable sample data can be arranged later through an agreed process.
- Practice domains and portfolio sites
List the brands, offices and websites your organization controls, including any separate project or campaign sites relevant to the concern.
- Publishing and media ownership
Identify who approves case studies, photography and downloadable resources, and who can retire older material.
- Enquiry routes and recipients
Describe the intended office or discipline handoff, scheduling provider and included CRM connections without sending prospect records.
- Document and collaboration boundaries
Explain whether resources are public, restricted on the site or hosted by another provider. Name the responsible administrator.
- Website and hosting contacts
Identify the maintainer, agency, host and practice contact able to authorize work. Mention a planned redesign or handover.
- Symptoms and timing
Share the affected public URL, expected behaviour and relevant recent changes. Leave out confidential drawings, models, site-access information and passwords.
Prepare a useful assessment and recovery brief.
These existing Defendoria guides help practice managers and website partners define checks, deliverables and recovery responsibilities.
Website Security Audit: What Should Be Checked?
A good website security audit makes decisions easier. It should identify what was reviewed, explain relevant risks in context, and give clear priorities rather than…
Website Backup and Recovery Plan for Small Businesses
A backup is valuable only when it helps restore working services. Build your recovery plan around the website, database, integrations and people the business depends…
Further technical guidance
Architecture and engineering website security questions.
Clarify the publishing routes, project-system boundaries and permissions before technical work begins.
Can you review a project portfolio without accessing confidential designs?
Yes. Begin with public URLs and the intended publishing workflow. The agreed website review can examine named pages, media routes and CMS permissions. Use approved non-sensitive examples for any restricted concern; confidential drawings or models are not needed for the initial enquiry.
Can you investigate old drawings or files still available online?
Describe the affected route and intended audience during scoping. Agreed checks can examine relevant website publication and access behaviour. Removing a page link and controlling the underlying file are different actions; remediation and evidence handling should be planned for the actual setup.
Does this include our common data environment or BIM platform?
Not automatically. Public links and included website-side settings can be reviewed. Authenticated collaboration systems, model repositories and provider infrastructure require separate authority, named environments and explicitly agreed methods.
Can you check project-enquiry forms and uploads?
The scope can include agreed form handling, recipients and relevant upload configuration. Functional checks use approved samples and a responsible contact. Do not send real project briefs, sensitive site information or private client records as test submissions.
Can you work with our design agency and hosting provider?
We can coordinate included website work with the responsible providers. Identify the content approver, technical maintainer and recovery owner. Any access changes or implementation work are agreed within the proposal.
What if the practice sells guides or training online?
Tell us whether the site has a genuine on-site checkout or links to another provider. WooCommerce security is relevant where WooCommerce is actually used. Any transactional testing needs suitable facilities and explicit scope; no live purchase is assumed.
Will this certify our designs or guarantee the website is secure?
No. The engagement provides website observations and actions within a defined scope. It does not validate designs, calculations, building-code compliance or professional credentials, and no website-security service can eliminate all risk.
Start with the website route your practice relies on.
Tell us about a portfolio, project enquiry, technical download, collaboration link or unexpected website behaviour. We can discuss a useful scope before requesting access.
- Public website
- Share the site or affected page.
- Intended journey
- Explain the expected next step and what concerns you.
- Responsible contact
- Identify the practice approver and current website maintainer.
Do not send confidential drawings, building models, tender documents, site-access details, client records, payment information or passwords. An enquiry does not authorize scanning or technical testing.
Discuss your practice website
Continue to the existing enquiry form with Architecture & Engineering selected. You can edit the message before choosing whether to send it.
Industry: Architecture & Engineering
Share your website and concern in the existing enquiry form. Your industry follows you into the request.
- A public website URL is enough to begin.
- Access and technical work require an agreed scope.
- Please leave out sensitive or confidential information.
You choose whether to send the form. This page does not submit an enquiry or start a scan.