Since this is a shared IIS server, I wouldn't consider data in RAM safe. At the very least, how do you ensure physical security of the server, console access, remote logon? Okay, this is a problem faced a lot though, and generally accepted practices prevail.

Supposing ActiveState Perl is installed, there are 2 ways Perl CGI can be run: in-process and out-of-process. Perl for ISAPI handles CGI's in-process and perl.exe handles them out-of-process.

Perl for ISAPI's perldoc says:

The main advantage of PerlIS over perl.exe is that PerlIS runs as a DLL in the web server's process space. Because Win32 platforms set up a protected memory space for each process that is started, there's a lot of overhead in starting a new process or program. Passing scripts to an interpreter, such as perl.exe, requires starting a new process for every script, which gets expensive in terms of system resources.

DLLs, on the other hand, don't need their own process space; they use the space of the process that calls them. They don't require nearly as much overhead to start, and once loaded they stay loaded until the calling process ends. PerlIS therefore runs Perl scripts with a quicker turn-around time than perl.exe.

Draw your own conclusions (from extensive testing).

There is also the possibility of a trojan perl.exe being installed on the server... how can you verify it? Or a trojan cgi script (if the ftp password is snagged--or file permissions are weak--or the shared admins are criminal). Yuk.

I would be paranoid... but I usually am. YMMV.

The first point from the ActiveState doc doesn't look right to me. The process space in which an ISAPI extension is run can be changed in the admin console. Typically (by default), an ISAPI DLL will be run by an external process called dllhost.exe. It is rare (and undesirable) to have an extension running in the IIS process space. The idea is that the executable host remains between calls (giving the advantage of not having to spawn a process) but an error in the ISAPI DLL won't crash the other IIS processes as it would if it were in process.

None of this really matters from a security point of view anyway as any program can debug any one of the IIS executables (or any other executable) and examine it's memory space as long as it has adequate access. The ability to debug an application can however be removed from all users on the system by updating the user rights assignment in the Local Security Policy manager.